From Yong.sc.Chen at huawei.com Mon Oct 1 15:27:39 2012 From: Yong.sc.Chen at huawei.com (Yong Chen) Date: Mon, 1 Oct 2012 22:27:39 +0000 Subject: [nvmewin] looking for help with IOCTL tool Message-ID: <02EC085151D99A469E06988E94FEBCDB1267A18E@szxeml535-mbx.china.huawei.com> Hi, everyone, My team is starting to work on Windows driver based on nvmewin reference driver. Thanks for sharing such excellent work. I have a question around IOCTL: which file path should I open in order to send the call to? The PT_IOCTL.doc in the library suggests to open file handle on \\.\ScsiN: before sending DeviceIoControl() down. Unfortunately, our Windows driver never receives anything. The SPTI tool sample in WDK says ScsiN: only works when the device is unclaimed by a SCSI driver. In the case, proper PathId, TargetId, and Lun must be set in the SCSI pass thru structure, but NVME_PASS_THROUGH_IOCTL doesn’t have these fields. According to MSDN, IOCTL send to storage class drivers are mapped to SRBs with function set to SRB_FUNCTION_EXECUTE_SCSI. If I open \\.\PhysicalDriveN, then I do receive SRBs with such Execute SCSI function code. But the current driver code expects SRB_FUNCTION_IO_CONTROL. How do you guys do it? Many thanks in advance, ________________________________ Yong Chen Storage Architect 华为技术有限公司 Huawei Technologies Co., Ltd [Company_logo]Office: 408-330-5482 Mobile: 425-922-0658 Email: yong.sc.chen at huawei.com 2330 Central Expressway Santa Clara, CA 95050 http://www.huawei.com 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 6737 bytes Desc: image002.jpg URL: From paul.e.luse at intel.com Mon Oct 1 16:02:39 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Mon, 1 Oct 2012 23:02:39 +0000 Subject: [nvmewin] ***UNCHECKED*** MSID 0 share w/IO queue patch Message-ID: <82C9F782B054C94B9FC04A331649C77A07B6E00E@FMSMSX106.amr.corp.intel.com> All- Here is the final patch for admin queue sharing and a few other misc cleanup items. Fully tested and I also reviewed w/Alex and Kwok F2F last week but will let Alex approve for himself. PW is intel123 Please let me know if there are any questions Thx Paul nvmeInit.c: - changes in loops and conditions to account for the number of cores now being the same as the number of vectors requested - removed unused element pMsiMsgTbl->CoreNum - removed unused element pMMT->CoreNum - in NVMeMsiMapCores(), now init the MsgId in the core table to the CQ number -1 (same as core #) - in DBG mode, track when learning is complete to support an assertion to make sure learning is always working - for the identify commands during the init state machine, we were DMA'ing directly into elements within devExt structures with no assurance of alignment. To address this I changed the target address of the xfer to use the driver state machine data buffer and copy it over on completion - NVMeAllocIoQueues(): fix to use an index that counts up through both core and NUMA loops (what Alex saw) instead of the inner loop. This val is used to index into the coreTable, the QueuId value will continue to behave as before and wrap at the number of queues nvmeIo.c: - two changes both wrapped in DBG, one to print PRP details and one to init the core # element in the srbExt used to make sure learning continues to do its job (check submitting core & completing core) nvmeStat.c - changes in loops and conditions to account for the number of cores now being the same as the number of vectors requested - init of the debug var used for learning mode nvmeStd.c - alloc one less entry for the MsgTable - in the completion routines (either DPC or ISR): -- switched the logic to check for the common case first (shared == FALSE) -- got rid of the learningMode var as we detect now based on startState as follows: If we're done with the init State machine: ? use the msg table to figure out which queue to look in Else if we're in learning mode: ? use the msgId + 1. Recall that when we alloc'd the queues we setup the CQ's such that QP 1 would use MSID0, QP 2 MSID 1, etc. Learning mode will loop through all of the QPs by walking the core table 0..number of cores. In the event that there are fewer QPs than cores because of an HBA limitation, this still works we just learn each queue more than once which does not hurt anything. Clearly when this happens things will not be optimal, they can't be without enough QPs, however we'll still fully utilize all of the available queue pairs - the loop has changed as the previous for loop didn't have the flexibility to check 2 non back-back queues. The QP that shared MSIX0 could be any of the other queues. I reworked the loops to be 2 do while loops and for an actual admin queue request we'll just check the admin queue, for the shared IO queue however we have to always check the admin queue as well. This logic is at the bottom of the loop and is fairly straightforward nvmeStd.h: - a few supporting changes - obvious Also made a few changes enar the end following review w/IDT: - replaced Rtl copy commands with storport copy commands - replaced Rtl zero mem commands with memset - added print at the end of learning mode to see updated mappings (initial mappings still print) ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: msix0.zip Type: application/x-zip-compressed Size: 169883 bytes Desc: msix0.zip URL: From paul.e.luse at intel.com Mon Oct 1 16:18:01 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Mon, 1 Oct 2012 23:18:01 +0000 Subject: [nvmewin] looking for help with IOCTL tool In-Reply-To: <02EC085151D99A469E06988E94FEBCDB1267A18E@szxeml535-mbx.china.huawei.com> References: <02EC085151D99A469E06988E94FEBCDB1267A18E@szxeml535-mbx.china.huawei.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A07B6E0CF@FMSMSX106.amr.corp.intel.com> Hi- To be clear, this is not a SCSI pass through request; this is an NVMe pass through command that we’ve encapsulated into an IOCTL that we send to the miniport. The guideline we wrote doesn’t specify how the app identifies the miniport and we don’t have sample code there and I suppose we probably should. Here’s some hacky example code that shows how your app can send a bunch of “identify IOCTLs” which you will have to define on your own (an IOCTL that just says “yes I’m a miniport that you are looking for”). This routine will keep a list of those adapters in an array of handles with the array index being the scsiport number where the miniport is at that you are interested in. So, in your driver quickly define an IOCTL and a handler that looks at a signature or whatever and responses success and this should work for you. There are more elegant ways of doing it but this should get you going Thx Paul int FindNlAdapters( HANDLE nlAdapters[], int maxHandles ) { int scsiPort; TCHAR buffer[64]; LPTSTR pszTxt = "\\\\.\\Scsi"; LPCTSTR pszFormat = "%s%d:"; size_t cchDest = 64; DWORD dw; NVME_PRIVATE_IOCTL myIoctl; int nlAdapterCount = 0; printf("FindNlAdapters: Searching ScsiPorts\n"); // Initialize nlAdapters array with 0s. memset(nlAdapters, 0, maxHandles * sizeof(HANDLE)); for (scsiPort = 0; scsiPort < maxHandles; scsiPort++) { wsprintf(buffer,pszFormat, pszTxt, scsiPort); HANDLE hand = CreateFile(buffer, GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); if (hand == INVALID_HANDLE_VALUE) { dw = GetLastError(); printf("didnt find %s err %d \n", buffer, dw); } else { printf("found %s \n", buffer); myIoctl.SrbIoCtrl.HeaderLength = sizeof(SRB_IO_CONTROL); memcpy(myIoctl.SrbIoCtrl.Signature, NVME_SIG_STR, sizeof(NVME_SIG_STR)); myIoctl.SrbIoCtrl.Timeout = 20; myIoctl.SrbIoCtrl.ControlCode = (ULONG)NL_IOCTL_IDENTIFY; myIoctl.SrbIoCtrl.ReturnCode = 0; myIoctl.SrbIoCtrl.Length = sizeof(NVME_PRIVATE_IOCTL) - sizeof(SRB_IO_CONTROL); BOOL b = DeviceIoControl(hand, IOCTL_SCSI_MINIPORT, &myIoctl, sizeof(myIoctl), &myIoctl, sizeof(myIoctl), &dw, NULL); if (FALSE == b) { printf("FindNlAdapters: NL_IOCTL_IDENTIFY: No NL miniport at this location %d\n" , scsiPort); CloseHandle(hand); } else { printf("FindNlAdapters: NL_IOCTL_IDENTIFY: NL miniport at this location %d !!!\n" , scsiPort); nlAdapters[scsiPort] = hand; nlAdapterCount++; } } } printf("FindNlAdapters: NL_IOCTL_IDENTIFY Success: nlAdapterCount: %d \n", nlAdapterCount); return nlAdapterCount; } From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Yong Chen Sent: Monday, October 01, 2012 3:28 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] looking for help with IOCTL tool Hi, everyone, My team is starting to work on Windows driver based on nvmewin reference driver. Thanks for sharing such excellent work. I have a question around IOCTL: which file path should I open in order to send the call to? The PT_IOCTL.doc in the library suggests to open file handle on \\.\ScsiN: before sending DeviceIoControl() down. Unfortunately, our Windows driver never receives anything. The SPTI tool sample in WDK says ScsiN: only works when the device is unclaimed by a SCSI driver. In the case, proper PathId, TargetId, and Lun must be set in the SCSI pass thru structure, but NVME_PASS_THROUGH_IOCTL doesn’t have these fields. According to MSDN, IOCTL send to storage class drivers are mapped to SRBs with function set to SRB_FUNCTION_EXECUTE_SCSI. If I open \\.\PhysicalDriveN, then I do receive SRBs with such Execute SCSI function code. But the current driver code expects SRB_FUNCTION_IO_CONTROL. How do you guys do it? Many thanks in advance, ________________________________ Yong Chen Storage Architect 华为技术有限公司 Huawei Technologies Co., Ltd [Company_logo]Office: 408-330-5482 Mobile: 425-922-0658 Email: yong.sc.chen at huawei.com 2330 Central Expressway Santa Clara, CA 95050 http://www.huawei.com 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 6737 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 1742 bytes Desc: image003.jpg URL: From james.p.freyensee at intel.com Mon Oct 1 19:04:29 2012 From: james.p.freyensee at intel.com (Freyensee, James P) Date: Tue, 2 Oct 2012 02:04:29 +0000 Subject: [nvmewin] Question on SntiTranslateWrite6() Message-ID: <2D98093777D3FD46A36253F35FE9D69346C3AF24@FMSMSX151.amr.corp.intel.com> I have a question in SntiTranslateWrite6(). Should this line: lba = GET_U32_FROM_CDB(pSrb, WRITE_6_CDB_LBA_OFFSET); actually be using the following MACRO mask, found in SntiTranslateRead6(): lba = GET_U24_FROM_CDB(pSrb, READ_6_CDB_LBA_OFFSET); I'm not totally clear on the different byte shifting and the different offsets being used between the two. However from the SCSI spec, the LBA bits are in the same spot in CDB[] for Write6 and Read6. So I would have assumed the byte shifting and offset algorithm and values would be the same. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Mon Oct 1 20:15:47 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Tue, 2 Oct 2012 03:15:47 +0000 Subject: [nvmewin] Question on SntiTranslateWrite6() In-Reply-To: <2D98093777D3FD46A36253F35FE9D69346C3AF24@FMSMSX151.amr.corp.intel.com> References: <2D98093777D3FD46A36253F35FE9D69346C3AF24@FMSMSX151.amr.corp.intel.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A07B6E734@FMSMSX106.amr.corp.intel.com> Yup, there's a few copy n paste errors here. In SntiTranslateWrite6() we should be using the 24 macro and in SntiTranslateRead6() we should be masking with READ_6_CDB_LBA_MASK for readability (it's the same as the write mask define). If you'd like some practice submitting a patch you can send one out with this and any other cleanup you might find after my patch in flight is pushed. I'd offer to throw these in mine but I've already tested with 2 HW platforms and QEMU and don't want to re-test J Thanks Paul From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Freyensee, James P Sent: Monday, October 01, 2012 7:04 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Question on SntiTranslateWrite6() I have a question in SntiTranslateWrite6(). Should this line: lba = GET_U32_FROM_CDB(pSrb, WRITE_6_CDB_LBA_OFFSET); actually be using the following MACRO mask, found in SntiTranslateRead6(): lba = GET_U24_FROM_CDB(pSrb, READ_6_CDB_LBA_OFFSET); I'm not totally clear on the different byte shifting and the different offsets being used between the two. However from the SCSI spec, the LBA bits are in the same spot in CDB[] for Write6 and Read6. So I would have assumed the byte shifting and offset algorithm and values would be the same. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From ngalbo at micron.com Tue Oct 2 07:00:55 2012 From: ngalbo at micron.com (Neal Galbo (ngalbo)) Date: Tue, 2 Oct 2012 14:00:55 +0000 Subject: [nvmewin] Question on SntiTranslateWrite6() In-Reply-To: <82C9F782B054C94B9FC04A331649C77A07B6E734@FMSMSX106.amr.corp.intel.com> References: <2D98093777D3FD46A36253F35FE9D69346C3AF24@FMSMSX151.amr.corp.intel.com> <82C9F782B054C94B9FC04A331649C77A07B6E734@FMSMSX106.amr.corp.intel.com> Message-ID: <5E6652408D93274292C8F06C9A4A260029C8550A@NTXBOIMBX05.micron.com> FYI, 6-byte SCSI READ/WRITE CDB's have a Big Endian 16-bit LBA. Shouldn't you be "getting" a U16? (GET_U16_FROM_CDB) Regards, Neal Galbo From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Monday, October 01, 2012 11:16 PM To: Freyensee, James P; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Question on SntiTranslateWrite6() Yup, there's a few copy n paste errors here. In SntiTranslateWrite6() we should be using the 24 macro and in SntiTranslateRead6() we should be masking with READ_6_CDB_LBA_MASK for readability (it's the same as the write mask define). If you'd like some practice submitting a patch you can send one out with this and any other cleanup you might find after my patch in flight is pushed. I'd offer to throw these in mine but I've already tested with 2 HW platforms and QEMU and don't want to re-test :) Thanks Paul From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Freyensee, James P Sent: Monday, October 01, 2012 7:04 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Question on SntiTranslateWrite6() I have a question in SntiTranslateWrite6(). Should this line: lba = GET_U32_FROM_CDB(pSrb, WRITE_6_CDB_LBA_OFFSET); actually be using the following MACRO mask, found in SntiTranslateRead6(): lba = GET_U24_FROM_CDB(pSrb, READ_6_CDB_LBA_OFFSET); I'm not totally clear on the different byte shifting and the different offsets being used between the two. However from the SCSI spec, the LBA bits are in the same spot in CDB[] for Write6 and Read6. So I would have assumed the byte shifting and offset algorithm and values would be the same. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Tue Oct 2 07:11:43 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Tue, 2 Oct 2012 14:11:43 +0000 Subject: [nvmewin] Question on SntiTranslateWrite6() In-Reply-To: <5E6652408D93274292C8F06C9A4A260029C8550A@NTXBOIMBX05.micron.com> References: <2D98093777D3FD46A36253F35FE9D69346C3AF24@FMSMSX151.amr.corp.intel.com> <82C9F782B054C94B9FC04A331649C77A07B6E734@FMSMSX106.amr.corp.intel.com> <5E6652408D93274292C8F06C9A4A260029C8550A@NTXBOIMBX05.micron.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A07B6EACD@FMSMSX106.amr.corp.intel.com> [cid:image001.png at 01CDA06D.2CEFE0D0] From: Neal Galbo (ngalbo) [mailto:ngalbo at micron.com] Sent: Tuesday, October 02, 2012 7:01 AM To: Luse, Paul E; Freyensee, James P; nvmewin at lists.openfabrics.org Subject: RE: Question on SntiTranslateWrite6() FYI, 6-byte SCSI READ/WRITE CDB's have a Big Endian 16-bit LBA. Shouldn't you be "getting" a U16? (GET_U16_FROM_CDB) Regards, Neal Galbo From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Monday, October 01, 2012 11:16 PM To: Freyensee, James P; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Question on SntiTranslateWrite6() Yup, there's a few copy n paste errors here. In SntiTranslateWrite6() we should be using the 24 macro and in SntiTranslateRead6() we should be masking with READ_6_CDB_LBA_MASK for readability (it's the same as the write mask define). If you'd like some practice submitting a patch you can send one out with this and any other cleanup you might find after my patch in flight is pushed. I'd offer to throw these in mine but I've already tested with 2 HW platforms and QEMU and don't want to re-test :) Thanks Paul From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Freyensee, James P Sent: Monday, October 01, 2012 7:04 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Question on SntiTranslateWrite6() I have a question in SntiTranslateWrite6(). Should this line: lba = GET_U32_FROM_CDB(pSrb, WRITE_6_CDB_LBA_OFFSET); actually be using the following MACRO mask, found in SntiTranslateRead6(): lba = GET_U24_FROM_CDB(pSrb, READ_6_CDB_LBA_OFFSET); I'm not totally clear on the different byte shifting and the different offsets being used between the two. However from the SCSI spec, the LBA bits are in the same spot in CDB[] for Write6 and Read6. So I would have assumed the byte shifting and offset algorithm and values would be the same. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 20878 bytes Desc: image001.png URL: From ngalbo at micron.com Tue Oct 2 08:10:34 2012 From: ngalbo at micron.com (Neal Galbo (ngalbo)) Date: Tue, 2 Oct 2012 15:10:34 +0000 Subject: [nvmewin] Question on SntiTranslateWrite6() In-Reply-To: <82C9F782B054C94B9FC04A331649C77A07B6EACD@FMSMSX106.amr.corp.intel.com> References: <2D98093777D3FD46A36253F35FE9D69346C3AF24@FMSMSX151.amr.corp.intel.com> <82C9F782B054C94B9FC04A331649C77A07B6E734@FMSMSX106.amr.corp.intel.com> <5E6652408D93274292C8F06C9A4A260029C8550A@NTXBOIMBX05.micron.com> <82C9F782B054C94B9FC04A331649C77A07B6EACD@FMSMSX106.amr.corp.intel.com> Message-ID: <5E6652408D93274292C8F06C9A4A260029C855C1@NTXBOIMBX05.micron.com> Sorry, I stand corrected. Thank you, Neal From: Luse, Paul E [mailto:paul.e.luse at intel.com] Sent: Tuesday, October 02, 2012 10:12 AM To: Neal Galbo (ngalbo); Freyensee, James P; nvmewin at lists.openfabrics.org Subject: RE: Question on SntiTranslateWrite6() [cid:image001.png at 01CDA08E.89D06AB0] From: Neal Galbo (ngalbo) [mailto:ngalbo at micron.com] Sent: Tuesday, October 02, 2012 7:01 AM To: Luse, Paul E; Freyensee, James P; nvmewin at lists.openfabrics.org Subject: RE: Question on SntiTranslateWrite6() FYI, 6-byte SCSI READ/WRITE CDB's have a Big Endian 16-bit LBA. Shouldn't you be "getting" a U16? (GET_U16_FROM_CDB) Regards, Neal Galbo From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Monday, October 01, 2012 11:16 PM To: Freyensee, James P; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Question on SntiTranslateWrite6() Yup, there's a few copy n paste errors here. In SntiTranslateWrite6() we should be using the 24 macro and in SntiTranslateRead6() we should be masking with READ_6_CDB_LBA_MASK for readability (it's the same as the write mask define). If you'd like some practice submitting a patch you can send one out with this and any other cleanup you might find after my patch in flight is pushed. I'd offer to throw these in mine but I've already tested with 2 HW platforms and QEMU and don't want to re-test :) Thanks Paul From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Freyensee, James P Sent: Monday, October 01, 2012 7:04 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Question on SntiTranslateWrite6() I have a question in SntiTranslateWrite6(). Should this line: lba = GET_U32_FROM_CDB(pSrb, WRITE_6_CDB_LBA_OFFSET); actually be using the following MACRO mask, found in SntiTranslateRead6(): lba = GET_U24_FROM_CDB(pSrb, READ_6_CDB_LBA_OFFSET); I'm not totally clear on the different byte shifting and the different offsets being used between the two. However from the SCSI spec, the LBA bits are in the same spot in CDB[] for Write6 and Read6. So I would have assumed the byte shifting and offset algorithm and values would be the same. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 20878 bytes Desc: image001.png URL: From paul.e.luse at intel.com Tue Oct 2 08:12:19 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Tue, 2 Oct 2012 15:12:19 +0000 Subject: [nvmewin] Question on SntiTranslateWrite6() In-Reply-To: <5E6652408D93274292C8F06C9A4A260029C855C1@NTXBOIMBX05.micron.com> References: <2D98093777D3FD46A36253F35FE9D69346C3AF24@FMSMSX151.amr.corp.intel.com> <82C9F782B054C94B9FC04A331649C77A07B6E734@FMSMSX106.amr.corp.intel.com> <5E6652408D93274292C8F06C9A4A260029C8550A@NTXBOIMBX05.micron.com> <82C9F782B054C94B9FC04A331649C77A07B6EACD@FMSMSX106.amr.corp.intel.com> <5E6652408D93274292C8F06C9A4A260029C855C1@NTXBOIMBX05.micron.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A07B6ED96@FMSMSX106.amr.corp.intel.com> No problem. Sorry, I meant to add a note to that email too - either my thought transcriber is not working or I'm doing too many things at once J From: Neal Galbo (ngalbo) [mailto:ngalbo at micron.com] Sent: Tuesday, October 02, 2012 8:11 AM To: Luse, Paul E; Freyensee, James P; nvmewin at lists.openfabrics.org Subject: RE: Question on SntiTranslateWrite6() Sorry, I stand corrected. Thank you, Neal From: Luse, Paul E [mailto:paul.e.luse at intel.com] Sent: Tuesday, October 02, 2012 10:12 AM To: Neal Galbo (ngalbo); Freyensee, James P; nvmewin at lists.openfabrics.org Subject: RE: Question on SntiTranslateWrite6() [cid:image001.png at 01CDA075.A41E2830] From: Neal Galbo (ngalbo) [mailto:ngalbo at micron.com] Sent: Tuesday, October 02, 2012 7:01 AM To: Luse, Paul E; Freyensee, James P; nvmewin at lists.openfabrics.org Subject: RE: Question on SntiTranslateWrite6() FYI, 6-byte SCSI READ/WRITE CDB's have a Big Endian 16-bit LBA. Shouldn't you be "getting" a U16? (GET_U16_FROM_CDB) Regards, Neal Galbo From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Monday, October 01, 2012 11:16 PM To: Freyensee, James P; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Question on SntiTranslateWrite6() Yup, there's a few copy n paste errors here. In SntiTranslateWrite6() we should be using the 24 macro and in SntiTranslateRead6() we should be masking with READ_6_CDB_LBA_MASK for readability (it's the same as the write mask define). If you'd like some practice submitting a patch you can send one out with this and any other cleanup you might find after my patch in flight is pushed. I'd offer to throw these in mine but I've already tested with 2 HW platforms and QEMU and don't want to re-test :) Thanks Paul From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Freyensee, James P Sent: Monday, October 01, 2012 7:04 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Question on SntiTranslateWrite6() I have a question in SntiTranslateWrite6(). Should this line: lba = GET_U32_FROM_CDB(pSrb, WRITE_6_CDB_LBA_OFFSET); actually be using the following MACRO mask, found in SntiTranslateRead6(): lba = GET_U24_FROM_CDB(pSrb, READ_6_CDB_LBA_OFFSET); I'm not totally clear on the different byte shifting and the different offsets being used between the two. However from the SCSI spec, the LBA bits are in the same spot in CDB[] for Write6 and Read6. So I would have assumed the byte shifting and offset algorithm and values would be the same. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 20878 bytes Desc: image001.png URL: From james.p.freyensee at intel.com Tue Oct 2 09:50:33 2012 From: james.p.freyensee at intel.com (Freyensee, James P) Date: Tue, 2 Oct 2012 16:50:33 +0000 Subject: [nvmewin] Question on SntiTranslateWrite6() In-Reply-To: <82C9F782B054C94B9FC04A331649C77A07B6E734@FMSMSX106.amr.corp.intel.com> References: <2D98093777D3FD46A36253F35FE9D69346C3AF24@FMSMSX151.amr.corp.intel.com> <82C9F782B054C94B9FC04A331649C77A07B6E734@FMSMSX106.amr.corp.intel.com> Message-ID: <2D98093777D3FD46A36253F35FE9D69346C3B5C8@FMSMSX151.amr.corp.intel.com> I can fix it and send a patch such that SntiTranslateWrite6() and SntiTranslateRead6() use the same bit-shift algorithm w/appropriate mask names, but I'm not in much of a position to test these specific changes out. I could probably get this done on Friday assuming your patch is pushed before then. I think I remember how to do the patch process because I did one months ago. Let me know if this is okay. Thanks, Jay From: Luse, Paul E Sent: Monday, October 01, 2012 8:16 PM To: Freyensee, James P; nvmewin at lists.openfabrics.org Subject: RE: Question on SntiTranslateWrite6() Yup, there's a few copy n paste errors here. In SntiTranslateWrite6() we should be using the 24 macro and in SntiTranslateRead6() we should be masking with READ_6_CDB_LBA_MASK for readability (it's the same as the write mask define). If you'd like some practice submitting a patch you can send one out with this and any other cleanup you might find after my patch in flight is pushed. I'd offer to throw these in mine but I've already tested with 2 HW platforms and QEMU and don't want to re-test :) Thanks Paul From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Freyensee, James P Sent: Monday, October 01, 2012 7:04 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Question on SntiTranslateWrite6() I have a question in SntiTranslateWrite6(). Should this line: lba = GET_U32_FROM_CDB(pSrb, WRITE_6_CDB_LBA_OFFSET); actually be using the following MACRO mask, found in SntiTranslateRead6(): lba = GET_U24_FROM_CDB(pSrb, READ_6_CDB_LBA_OFFSET); I'm not totally clear on the different byte shifting and the different offsets being used between the two. However from the SCSI spec, the LBA bits are in the same spot in CDB[] for Write6 and Read6. So I would have assumed the byte shifting and offset algorithm and values would be the same. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Tue Oct 2 09:51:59 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Tue, 2 Oct 2012 16:51:59 +0000 Subject: [nvmewin] Question on SntiTranslateWrite6() In-Reply-To: <2D98093777D3FD46A36253F35FE9D69346C3B5C8@FMSMSX151.amr.corp.intel.com> References: <2D98093777D3FD46A36253F35FE9D69346C3AF24@FMSMSX151.amr.corp.intel.com> <82C9F782B054C94B9FC04A331649C77A07B6E734@FMSMSX106.amr.corp.intel.com> <2D98093777D3FD46A36253F35FE9D69346C3B5C8@FMSMSX151.amr.corp.intel.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A07B6F0EC@FMSMSX106.amr.corp.intel.com> There's certainly no hurry - a few weeks is even fine. I'll sync w/you offline to make sure you're setup to test w/qemu Thx Paul From: Freyensee, James P Sent: Tuesday, October 02, 2012 9:51 AM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: Question on SntiTranslateWrite6() I can fix it and send a patch such that SntiTranslateWrite6() and SntiTranslateRead6() use the same bit-shift algorithm w/appropriate mask names, but I'm not in much of a position to test these specific changes out. I could probably get this done on Friday assuming your patch is pushed before then. I think I remember how to do the patch process because I did one months ago. Let me know if this is okay. Thanks, Jay From: Luse, Paul E Sent: Monday, October 01, 2012 8:16 PM To: Freyensee, James P; nvmewin at lists.openfabrics.org Subject: RE: Question on SntiTranslateWrite6() Yup, there's a few copy n paste errors here. In SntiTranslateWrite6() we should be using the 24 macro and in SntiTranslateRead6() we should be masking with READ_6_CDB_LBA_MASK for readability (it's the same as the write mask define). If you'd like some practice submitting a patch you can send one out with this and any other cleanup you might find after my patch in flight is pushed. I'd offer to throw these in mine but I've already tested with 2 HW platforms and QEMU and don't want to re-test :) Thanks Paul From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Freyensee, James P Sent: Monday, October 01, 2012 7:04 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Question on SntiTranslateWrite6() I have a question in SntiTranslateWrite6(). Should this line: lba = GET_U32_FROM_CDB(pSrb, WRITE_6_CDB_LBA_OFFSET); actually be using the following MACRO mask, found in SntiTranslateRead6(): lba = GET_U24_FROM_CDB(pSrb, READ_6_CDB_LBA_OFFSET); I'm not totally clear on the different byte shifting and the different offsets being used between the two. However from the SCSI spec, the LBA bits are in the same spot in CDB[] for Write6 and Read6. So I would have assumed the byte shifting and offset algorithm and values would be the same. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Tue Oct 2 10:00:40 2012 From: Alex.Chang at idt.com (Chang, Alex) Date: Tue, 2 Oct 2012 17:00:40 +0000 Subject: [nvmewin] MSID 0 share w/IO queue patch In-Reply-To: <82C9F782B054C94B9FC04A331649C77A07B6E00E@FMSMSX106.amr.corp.intel.com> References: <82C9F782B054C94B9FC04A331649C77A07B6E00E@FMSMSX106.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D3602B83D97@corpmail1.na.ads.idt.com> Hi Paul, After reviewing the changes you made, I have couple of feedbacks: 1. In Line#1673, where handles pending entries in AdminQ that shares Msg#0 with another queue: if ((firstCheckQueue > 0) && (MsgID == 0)) { firstCheckQueue = lastCheckQueue = indexCheckQueue = 0; } Just in case that happens to have pending entries in AdminQ during learning phase (which is quite unlikely), we should add one more checking: if ((firstCheckQueue > 0) && (pAE->DriverState.NextDriverState != NVMeWaitOnLearnMapping) && (MsgID == 0)) { firstCheckQueue = lastCheckQueue = indexCheckQueue = 0; } 2. Could you add the core-vector mapping result after discovered? #if DBG StorPortDebugPrint(INFO, "Mapping learned: Core(%02d) <=> Vector(%02d)\n", procNum.Number, MsgID); #endif Will do more testing and get back to you by Friday. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Monday, October 01, 2012 4:03 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** MSID 0 share w/IO queue patch All- Here is the final patch for admin queue sharing and a few other misc cleanup items. Fully tested and I also reviewed w/Alex and Kwok F2F last week but will let Alex approve for himself. PW is intel123 Please let me know if there are any questions Thx Paul nvmeInit.c: - changes in loops and conditions to account for the number of cores now being the same as the number of vectors requested - removed unused element pMsiMsgTbl->CoreNum - removed unused element pMMT->CoreNum - in NVMeMsiMapCores(), now init the MsgId in the core table to the CQ number -1 (same as core #) - in DBG mode, track when learning is complete to support an assertion to make sure learning is always working - for the identify commands during the init state machine, we were DMA'ing directly into elements within devExt structures with no assurance of alignment. To address this I changed the target address of the xfer to use the driver state machine data buffer and copy it over on completion - NVMeAllocIoQueues(): fix to use an index that counts up through both core and NUMA loops (what Alex saw) instead of the inner loop. This val is used to index into the coreTable, the QueuId value will continue to behave as before and wrap at the number of queues nvmeIo.c: - two changes both wrapped in DBG, one to print PRP details and one to init the core # element in the srbExt used to make sure learning continues to do its job (check submitting core & completing core) nvmeStat.c - changes in loops and conditions to account for the number of cores now being the same as the number of vectors requested - init of the debug var used for learning mode nvmeStd.c - alloc one less entry for the MsgTable - in the completion routines (either DPC or ISR): -- switched the logic to check for the common case first (shared == FALSE) -- got rid of the learningMode var as we detect now based on startState as follows: If we're done with the init State machine: ? use the msg table to figure out which queue to look in Else if we're in learning mode: ? use the msgId + 1. Recall that when we alloc'd the queues we setup the CQ's such that QP 1 would use MSID0, QP 2 MSID 1, etc. Learning mode will loop through all of the QPs by walking the core table 0..number of cores. In the event that there are fewer QPs than cores because of an HBA limitation, this still works we just learn each queue more than once which does not hurt anything. Clearly when this happens things will not be optimal, they can't be without enough QPs, however we'll still fully utilize all of the available queue pairs - the loop has changed as the previous for loop didn't have the flexibility to check 2 non back-back queues. The QP that shared MSIX0 could be any of the other queues. I reworked the loops to be 2 do while loops and for an actual admin queue request we'll just check the admin queue, for the shared IO queue however we have to always check the admin queue as well. This logic is at the bottom of the loop and is fairly straightforward nvmeStd.h: - a few supporting changes - obvious Also made a few changes enar the end following review w/IDT: - replaced Rtl copy commands with storport copy commands - replaced Rtl zero mem commands with memset - added print at the end of learning mode to see updated mappings (initial mappings still print) ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Tue Oct 2 10:12:55 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Tue, 2 Oct 2012 17:12:55 +0000 Subject: [nvmewin] MSID 0 share w/IO queue patch In-Reply-To: <548C5470AAD9DA4A85D259B663190D3602B83D97@corpmail1.na.ads.idt.com> References: <82C9F782B054C94B9FC04A331649C77A07B6E00E@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D3602B83D97@corpmail1.na.ads.idt.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A07B6F21F@FMSMSX106.amr.corp.intel.com> Hi Alex- Thanks for the review! Item (1) is not possible today, during learning we are single threaded in the init state machine and IOs are held off from storport; there's no way anything else can come through. If someone were to introduce an admin command in the code during learning phase they would run into a problem that they would discover immediately (they would miss the INT on the admin command) but I don't see that happening and it can be addressed at that time if it does. Resisting this change because (a) it can't happen now and is unlikely to happen in the future and (b) the extra check is in the IO path so shouldn't be added unless needed. Are you OK with that? On item 2, I already do that however I don't print it in the ISR/DPC as we learn, I do it at the very end so its easier to print out/see on the debugger. Its in the init callback near the end: #if DBG PRES_MAPPING_TBL pRMT = &pAE->ResMapTbl; PCORE_TBL pCT = NULL; ULONG i; /* print out the learned table */ StorPortDebugPrint(INFO, "Learning Complete. Core Table:\n"); for (i=0; i < pRMT->NumActiveCores; i++) { pCT = pRMT->pCoreTbl + i; StorPortDebugPrint(INFO, "\tCore(0x%x) MSID(0x%x) QueuePair(0x%x)\n", pCT->CoreNum, pCT->MsiMsgID, pCT->SubQueue); } pAE->LearningComplete = TRUE; #endif From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, October 02, 2012 10:01 AM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: MSID 0 share w/IO queue patch Hi Paul, After reviewing the changes you made, I have couple of feedbacks: 1. In Line#1673, where handles pending entries in AdminQ that shares Msg#0 with another queue: if ((firstCheckQueue > 0) && (MsgID == 0)) { firstCheckQueue = lastCheckQueue = indexCheckQueue = 0; } Just in case that happens to have pending entries in AdminQ during learning phase (which is quite unlikely), we should add one more checking: if ((firstCheckQueue > 0) && (pAE->DriverState.NextDriverState != NVMeWaitOnLearnMapping) && (MsgID == 0)) { firstCheckQueue = lastCheckQueue = indexCheckQueue = 0; } 2. Could you add the core-vector mapping result after discovered? #if DBG StorPortDebugPrint(INFO, "Mapping learned: Core(%02d) <=> Vector(%02d)\n", procNum.Number, MsgID); #endif Will do more testing and get back to you by Friday. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Monday, October 01, 2012 4:03 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** MSID 0 share w/IO queue patch All- Here is the final patch for admin queue sharing and a few other misc cleanup items. Fully tested and I also reviewed w/Alex and Kwok F2F last week but will let Alex approve for himself. PW is intel123 Please let me know if there are any questions Thx Paul nvmeInit.c: - changes in loops and conditions to account for the number of cores now being the same as the number of vectors requested - removed unused element pMsiMsgTbl->CoreNum - removed unused element pMMT->CoreNum - in NVMeMsiMapCores(), now init the MsgId in the core table to the CQ number -1 (same as core #) - in DBG mode, track when learning is complete to support an assertion to make sure learning is always working - for the identify commands during the init state machine, we were DMA'ing directly into elements within devExt structures with no assurance of alignment. To address this I changed the target address of the xfer to use the driver state machine data buffer and copy it over on completion - NVMeAllocIoQueues(): fix to use an index that counts up through both core and NUMA loops (what Alex saw) instead of the inner loop. This val is used to index into the coreTable, the QueuId value will continue to behave as before and wrap at the number of queues nvmeIo.c: - two changes both wrapped in DBG, one to print PRP details and one to init the core # element in the srbExt used to make sure learning continues to do its job (check submitting core & completing core) nvmeStat.c - changes in loops and conditions to account for the number of cores now being the same as the number of vectors requested - init of the debug var used for learning mode nvmeStd.c - alloc one less entry for the MsgTable - in the completion routines (either DPC or ISR): -- switched the logic to check for the common case first (shared == FALSE) -- got rid of the learningMode var as we detect now based on startState as follows: If we're done with the init State machine: ? use the msg table to figure out which queue to look in Else if we're in learning mode: ? use the msgId + 1. Recall that when we alloc'd the queues we setup the CQ's such that QP 1 would use MSID0, QP 2 MSID 1, etc. Learning mode will loop through all of the QPs by walking the core table 0..number of cores. In the event that there are fewer QPs than cores because of an HBA limitation, this still works we just learn each queue more than once which does not hurt anything. Clearly when this happens things will not be optimal, they can't be without enough QPs, however we'll still fully utilize all of the available queue pairs - the loop has changed as the previous for loop didn't have the flexibility to check 2 non back-back queues. The QP that shared MSIX0 could be any of the other queues. I reworked the loops to be 2 do while loops and for an actual admin queue request we'll just check the admin queue, for the shared IO queue however we have to always check the admin queue as well. This logic is at the bottom of the loop and is fairly straightforward nvmeStd.h: - a few supporting changes - obvious Also made a few changes enar the end following review w/IDT: - replaced Rtl copy commands with storport copy commands - replaced Rtl zero mem commands with memset - added print at the end of learning mode to see updated mappings (initial mappings still print) ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Tue Oct 2 10:31:19 2012 From: Alex.Chang at idt.com (Chang, Alex) Date: Tue, 2 Oct 2012 17:31:19 +0000 Subject: [nvmewin] MSID 0 share w/IO queue patch In-Reply-To: <82C9F782B054C94B9FC04A331649C77A07B6F21F@FMSMSX106.amr.corp.intel.com> References: <82C9F782B054C94B9FC04A331649C77A07B6E00E@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D3602B83D97@corpmail1.na.ads.idt.com> <82C9F782B054C94B9FC04A331649C77A07B6F21F@FMSMSX106.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D3602B83DB8@corpmail1.na.ads.idt.com> Paul, I agree. Like I motioned it's quite unlikely from driver's current state machine implementation. The reason I brought it up is the state machine relies on "LearningCores" to determine if moving out of learning phase and the value of LearningCores might be incorrect if, for some reasons, the AdminQ has pending completion entries or there are more than one completion entries in any given IO queue. Anyway, it's just a suggestion and let's make a note for now. Thanks, Alex ________________________________ From: Luse, Paul E [mailto:paul.e.luse at intel.com] Sent: Tuesday, October 02, 2012 10:13 AM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: MSID 0 share w/IO queue patch Hi Alex- Thanks for the review! Item (1) is not possible today, during learning we are single threaded in the init state machine and IOs are held off from storport; there's no way anything else can come through. If someone were to introduce an admin command in the code during learning phase they would run into a problem that they would discover immediately (they would miss the INT on the admin command) but I don't see that happening and it can be addressed at that time if it does. Resisting this change because (a) it can't happen now and is unlikely to happen in the future and (b) the extra check is in the IO path so shouldn't be added unless needed. Are you OK with that? On item 2, I already do that however I don't print it in the ISR/DPC as we learn, I do it at the very end so its easier to print out/see on the debugger. Its in the init callback near the end: #if DBG PRES_MAPPING_TBL pRMT = &pAE->ResMapTbl; PCORE_TBL pCT = NULL; ULONG i; /* print out the learned table */ StorPortDebugPrint(INFO, "Learning Complete. Core Table:\n"); for (i=0; i < pRMT->NumActiveCores; i++) { pCT = pRMT->pCoreTbl + i; StorPortDebugPrint(INFO, "\tCore(0x%x) MSID(0x%x) QueuePair(0x%x)\n", pCT->CoreNum, pCT->MsiMsgID, pCT->SubQueue); } pAE->LearningComplete = TRUE; #endif From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, October 02, 2012 10:01 AM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: MSID 0 share w/IO queue patch Hi Paul, After reviewing the changes you made, I have couple of feedbacks: 1. In Line#1673, where handles pending entries in AdminQ that shares Msg#0 with another queue: if ((firstCheckQueue > 0) && (MsgID == 0)) { firstCheckQueue = lastCheckQueue = indexCheckQueue = 0; } Just in case that happens to have pending entries in AdminQ during learning phase (which is quite unlikely), we should add one more checking: if ((firstCheckQueue > 0) && (pAE->DriverState.NextDriverState != NVMeWaitOnLearnMapping) && (MsgID == 0)) { firstCheckQueue = lastCheckQueue = indexCheckQueue = 0; } 2. Could you add the core-vector mapping result after discovered? #if DBG StorPortDebugPrint(INFO, "Mapping learned: Core(%02d) <=> Vector(%02d)\n", procNum.Number, MsgID); #endif Will do more testing and get back to you by Friday. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Monday, October 01, 2012 4:03 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** MSID 0 share w/IO queue patch All- Here is the final patch for admin queue sharing and a few other misc cleanup items. Fully tested and I also reviewed w/Alex and Kwok F2F last week but will let Alex approve for himself. PW is intel123 Please let me know if there are any questions Thx Paul nvmeInit.c: - changes in loops and conditions to account for the number of cores now being the same as the number of vectors requested - removed unused element pMsiMsgTbl->CoreNum - removed unused element pMMT->CoreNum - in NVMeMsiMapCores(), now init the MsgId in the core table to the CQ number -1 (same as core #) - in DBG mode, track when learning is complete to support an assertion to make sure learning is always working - for the identify commands during the init state machine, we were DMA'ing directly into elements within devExt structures with no assurance of alignment. To address this I changed the target address of the xfer to use the driver state machine data buffer and copy it over on completion - NVMeAllocIoQueues(): fix to use an index that counts up through both core and NUMA loops (what Alex saw) instead of the inner loop. This val is used to index into the coreTable, the QueuId value will continue to behave as before and wrap at the number of queues nvmeIo.c: - two changes both wrapped in DBG, one to print PRP details and one to init the core # element in the srbExt used to make sure learning continues to do its job (check submitting core & completing core) nvmeStat.c - changes in loops and conditions to account for the number of cores now being the same as the number of vectors requested - init of the debug var used for learning mode nvmeStd.c - alloc one less entry for the MsgTable - in the completion routines (either DPC or ISR): -- switched the logic to check for the common case first (shared == FALSE) -- got rid of the learningMode var as we detect now based on startState as follows: If we're done with the init State machine: ? use the msg table to figure out which queue to look in Else if we're in learning mode: ? use the msgId + 1. Recall that when we alloc'd the queues we setup the CQ's such that QP 1 would use MSID0, QP 2 MSID 1, etc. Learning mode will loop through all of the QPs by walking the core table 0..number of cores. In the event that there are fewer QPs than cores because of an HBA limitation, this still works we just learn each queue more than once which does not hurt anything. Clearly when this happens things will not be optimal, they can't be without enough QPs, however we'll still fully utilize all of the available queue pairs - the loop has changed as the previous for loop didn't have the flexibility to check 2 non back-back queues. The QP that shared MSIX0 could be any of the other queues. I reworked the loops to be 2 do while loops and for an actual admin queue request we'll just check the admin queue, for the shared IO queue however we have to always check the admin queue as well. This logic is at the bottom of the loop and is fairly straightforward nvmeStd.h: - a few supporting changes - obvious Also made a few changes enar the end following review w/IDT: - replaced Rtl copy commands with storport copy commands - replaced Rtl zero mem commands with memset - added print at the end of learning mode to see updated mappings (initial mappings still print) ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Tue Oct 2 10:34:01 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Tue, 2 Oct 2012 17:34:01 +0000 Subject: [nvmewin] MSID 0 share w/IO queue patch In-Reply-To: <548C5470AAD9DA4A85D259B663190D3602B83DB8@corpmail1.na.ads.idt.com> References: <82C9F782B054C94B9FC04A331649C77A07B6E00E@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D3602B83D97@corpmail1.na.ads.idt.com> <82C9F782B054C94B9FC04A331649C77A07B6F21F@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D3602B83DB8@corpmail1.na.ads.idt.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A07B6F358@FMSMSX106.amr.corp.intel.com> Cool, thanks. I assume you are OK with the prints too (I did it that way so the table is displayed in core order). Anyway, let us know when you're done testing. Rick/Arpit, any chance yet to take a look? Not in any big hurry, just checking. Thx Paul From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, October 02, 2012 10:31 AM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: MSID 0 share w/IO queue patch Paul, I agree. Like I motioned it's quite unlikely from driver's current state machine implementation. The reason I brought it up is the state machine relies on "LearningCores" to determine if moving out of learning phase and the value of LearningCores might be incorrect if, for some reasons, the AdminQ has pending completion entries or there are more than one completion entries in any given IO queue. Anyway, it's just a suggestion and let's make a note for now. Thanks, Alex ________________________________ From: Luse, Paul E [mailto:paul.e.luse at intel.com] Sent: Tuesday, October 02, 2012 10:13 AM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: MSID 0 share w/IO queue patch Hi Alex- Thanks for the review! Item (1) is not possible today, during learning we are single threaded in the init state machine and IOs are held off from storport; there's no way anything else can come through. If someone were to introduce an admin command in the code during learning phase they would run into a problem that they would discover immediately (they would miss the INT on the admin command) but I don't see that happening and it can be addressed at that time if it does. Resisting this change because (a) it can't happen now and is unlikely to happen in the future and (b) the extra check is in the IO path so shouldn't be added unless needed. Are you OK with that? On item 2, I already do that however I don't print it in the ISR/DPC as we learn, I do it at the very end so its easier to print out/see on the debugger. Its in the init callback near the end: #if DBG PRES_MAPPING_TBL pRMT = &pAE->ResMapTbl; PCORE_TBL pCT = NULL; ULONG i; /* print out the learned table */ StorPortDebugPrint(INFO, "Learning Complete. Core Table:\n"); for (i=0; i < pRMT->NumActiveCores; i++) { pCT = pRMT->pCoreTbl + i; StorPortDebugPrint(INFO, "\tCore(0x%x) MSID(0x%x) QueuePair(0x%x)\n", pCT->CoreNum, pCT->MsiMsgID, pCT->SubQueue); } pAE->LearningComplete = TRUE; #endif From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, October 02, 2012 10:01 AM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: MSID 0 share w/IO queue patch Hi Paul, After reviewing the changes you made, I have couple of feedbacks: 1. In Line#1673, where handles pending entries in AdminQ that shares Msg#0 with another queue: if ((firstCheckQueue > 0) && (MsgID == 0)) { firstCheckQueue = lastCheckQueue = indexCheckQueue = 0; } Just in case that happens to have pending entries in AdminQ during learning phase (which is quite unlikely), we should add one more checking: if ((firstCheckQueue > 0) && (pAE->DriverState.NextDriverState != NVMeWaitOnLearnMapping) && (MsgID == 0)) { firstCheckQueue = lastCheckQueue = indexCheckQueue = 0; } 2. Could you add the core-vector mapping result after discovered? #if DBG StorPortDebugPrint(INFO, "Mapping learned: Core(%02d) <=> Vector(%02d)\n", procNum.Number, MsgID); #endif Will do more testing and get back to you by Friday. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Monday, October 01, 2012 4:03 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** MSID 0 share w/IO queue patch All- Here is the final patch for admin queue sharing and a few other misc cleanup items. Fully tested and I also reviewed w/Alex and Kwok F2F last week but will let Alex approve for himself. PW is intel123 Please let me know if there are any questions Thx Paul nvmeInit.c: - changes in loops and conditions to account for the number of cores now being the same as the number of vectors requested - removed unused element pMsiMsgTbl->CoreNum - removed unused element pMMT->CoreNum - in NVMeMsiMapCores(), now init the MsgId in the core table to the CQ number -1 (same as core #) - in DBG mode, track when learning is complete to support an assertion to make sure learning is always working - for the identify commands during the init state machine, we were DMA'ing directly into elements within devExt structures with no assurance of alignment. To address this I changed the target address of the xfer to use the driver state machine data buffer and copy it over on completion - NVMeAllocIoQueues(): fix to use an index that counts up through both core and NUMA loops (what Alex saw) instead of the inner loop. This val is used to index into the coreTable, the QueuId value will continue to behave as before and wrap at the number of queues nvmeIo.c: - two changes both wrapped in DBG, one to print PRP details and one to init the core # element in the srbExt used to make sure learning continues to do its job (check submitting core & completing core) nvmeStat.c - changes in loops and conditions to account for the number of cores now being the same as the number of vectors requested - init of the debug var used for learning mode nvmeStd.c - alloc one less entry for the MsgTable - in the completion routines (either DPC or ISR): -- switched the logic to check for the common case first (shared == FALSE) -- got rid of the learningMode var as we detect now based on startState as follows: If we're done with the init State machine: ? use the msg table to figure out which queue to look in Else if we're in learning mode: ? use the msgId + 1. Recall that when we alloc'd the queues we setup the CQ's such that QP 1 would use MSID0, QP 2 MSID 1, etc. Learning mode will loop through all of the QPs by walking the core table 0..number of cores. In the event that there are fewer QPs than cores because of an HBA limitation, this still works we just learn each queue more than once which does not hurt anything. Clearly when this happens things will not be optimal, they can't be without enough QPs, however we'll still fully utilize all of the available queue pairs - the loop has changed as the previous for loop didn't have the flexibility to check 2 non back-back queues. The QP that shared MSIX0 could be any of the other queues. I reworked the loops to be 2 do while loops and for an actual admin queue request we'll just check the admin queue, for the shared IO queue however we have to always check the admin queue as well. This logic is at the bottom of the loop and is fairly straightforward nvmeStd.h: - a few supporting changes - obvious Also made a few changes enar the end following review w/IDT: - replaced Rtl copy commands with storport copy commands - replaced Rtl zero mem commands with memset - added print at the end of learning mode to see updated mappings (initial mappings still print) ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Fri Oct 5 15:18:32 2012 From: Alex.Chang at idt.com (Chang, Alex) Date: Fri, 5 Oct 2012 22:18:32 +0000 Subject: [nvmewin] MSID 0 share w/IO queue patch In-Reply-To: <82C9F782B054C94B9FC04A331649C77A07B6E00E@FMSMSX106.amr.corp.intel.com> References: <82C9F782B054C94B9FC04A331649C77A07B6E00E@FMSMSX106.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361DDB5A1A@corpmail2.na.ads.idt.com> Hi Paul, We are good with the patch. Thanks a lot for the effort. Regards, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Monday, October 01, 2012 4:03 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** MSID 0 share w/IO queue patch All- Here is the final patch for admin queue sharing and a few other misc cleanup items. Fully tested and I also reviewed w/Alex and Kwok F2F last week but will let Alex approve for himself. PW is intel123 Please let me know if there are any questions Thx Paul nvmeInit.c: - changes in loops and conditions to account for the number of cores now being the same as the number of vectors requested - removed unused element pMsiMsgTbl->CoreNum - removed unused element pMMT->CoreNum - in NVMeMsiMapCores(), now init the MsgId in the core table to the CQ number -1 (same as core #) - in DBG mode, track when learning is complete to support an assertion to make sure learning is always working - for the identify commands during the init state machine, we were DMA'ing directly into elements within devExt structures with no assurance of alignment. To address this I changed the target address of the xfer to use the driver state machine data buffer and copy it over on completion - NVMeAllocIoQueues(): fix to use an index that counts up through both core and NUMA loops (what Alex saw) instead of the inner loop. This val is used to index into the coreTable, the QueuId value will continue to behave as before and wrap at the number of queues nvmeIo.c: - two changes both wrapped in DBG, one to print PRP details and one to init the core # element in the srbExt used to make sure learning continues to do its job (check submitting core & completing core) nvmeStat.c - changes in loops and conditions to account for the number of cores now being the same as the number of vectors requested - init of the debug var used for learning mode nvmeStd.c - alloc one less entry for the MsgTable - in the completion routines (either DPC or ISR): -- switched the logic to check for the common case first (shared == FALSE) -- got rid of the learningMode var as we detect now based on startState as follows: If we're done with the init State machine: ? use the msg table to figure out which queue to look in Else if we're in learning mode: ? use the msgId + 1. Recall that when we alloc'd the queues we setup the CQ's such that QP 1 would use MSID0, QP 2 MSID 1, etc. Learning mode will loop through all of the QPs by walking the core table 0..number of cores. In the event that there are fewer QPs than cores because of an HBA limitation, this still works we just learn each queue more than once which does not hurt anything. Clearly when this happens things will not be optimal, they can't be without enough QPs, however we'll still fully utilize all of the available queue pairs - the loop has changed as the previous for loop didn't have the flexibility to check 2 non back-back queues. The QP that shared MSIX0 could be any of the other queues. I reworked the loops to be 2 do while loops and for an actual admin queue request we'll just check the admin queue, for the shared IO queue however we have to always check the admin queue as well. This logic is at the bottom of the loop and is fairly straightforward nvmeStd.h: - a few supporting changes - obvious Also made a few changes enar the end following review w/IDT: - replaced Rtl copy commands with storport copy commands - replaced Rtl zero mem commands with memset - added print at the end of learning mode to see updated mappings (initial mappings still print) ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Fri Oct 5 15:23:31 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Fri, 5 Oct 2012 22:23:31 +0000 Subject: [nvmewin] MSID 0 share w/IO queue patch In-Reply-To: <548C5470AAD9DA4A85D259B663190D361DDB5A1A@corpmail2.na.ads.idt.com> References: <82C9F782B054C94B9FC04A331649C77A07B6E00E@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361DDB5A1A@corpmail2.na.ads.idt.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A07B74E31@FMSMSX106.amr.corp.intel.com> Thanks Alex. Rick or Arpit, have you guys had a chance to review yet? Thx Paul From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Friday, October 05, 2012 3:19 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: MSID 0 share w/IO queue patch Hi Paul, We are good with the patch. Thanks a lot for the effort. Regards, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Monday, October 01, 2012 4:03 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** MSID 0 share w/IO queue patch All- Here is the final patch for admin queue sharing and a few other misc cleanup items. Fully tested and I also reviewed w/Alex and Kwok F2F last week but will let Alex approve for himself. PW is intel123 Please let me know if there are any questions Thx Paul nvmeInit.c: - changes in loops and conditions to account for the number of cores now being the same as the number of vectors requested - removed unused element pMsiMsgTbl->CoreNum - removed unused element pMMT->CoreNum - in NVMeMsiMapCores(), now init the MsgId in the core table to the CQ number -1 (same as core #) - in DBG mode, track when learning is complete to support an assertion to make sure learning is always working - for the identify commands during the init state machine, we were DMA'ing directly into elements within devExt structures with no assurance of alignment. To address this I changed the target address of the xfer to use the driver state machine data buffer and copy it over on completion - NVMeAllocIoQueues(): fix to use an index that counts up through both core and NUMA loops (what Alex saw) instead of the inner loop. This val is used to index into the coreTable, the QueuId value will continue to behave as before and wrap at the number of queues nvmeIo.c: - two changes both wrapped in DBG, one to print PRP details and one to init the core # element in the srbExt used to make sure learning continues to do its job (check submitting core & completing core) nvmeStat.c - changes in loops and conditions to account for the number of cores now being the same as the number of vectors requested - init of the debug var used for learning mode nvmeStd.c - alloc one less entry for the MsgTable - in the completion routines (either DPC or ISR): -- switched the logic to check for the common case first (shared == FALSE) -- got rid of the learningMode var as we detect now based on startState as follows: If we're done with the init State machine: ? use the msg table to figure out which queue to look in Else if we're in learning mode: ? use the msgId + 1. Recall that when we alloc'd the queues we setup the CQ's such that QP 1 would use MSID0, QP 2 MSID 1, etc. Learning mode will loop through all of the QPs by walking the core table 0..number of cores. In the event that there are fewer QPs than cores because of an HBA limitation, this still works we just learn each queue more than once which does not hurt anything. Clearly when this happens things will not be optimal, they can't be without enough QPs, however we'll still fully utilize all of the available queue pairs - the loop has changed as the previous for loop didn't have the flexibility to check 2 non back-back queues. The QP that shared MSIX0 could be any of the other queues. I reworked the loops to be 2 do while loops and for an actual admin queue request we'll just check the admin queue, for the shared IO queue however we have to always check the admin queue as well. This logic is at the bottom of the loop and is fairly straightforward nvmeStd.h: - a few supporting changes - obvious Also made a few changes enar the end following review w/IDT: - replaced Rtl copy commands with storport copy commands - replaced Rtl zero mem commands with memset - added print at the end of learning mode to see updated mappings (initial mappings still print) ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Arpit.Patel at lsi.com Fri Oct 5 17:15:31 2012 From: Arpit.Patel at lsi.com (Patel, Arpit) Date: Fri, 5 Oct 2012 18:15:31 -0600 Subject: [nvmewin] MSID 0 share w/IO queue patch In-Reply-To: <82C9F782B054C94B9FC04A331649C77A07B74E31@FMSMSX106.amr.corp.intel.com> References: <82C9F782B054C94B9FC04A331649C77A07B6E00E@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361DDB5A1A@corpmail2.na.ads.idt.com> <82C9F782B054C94B9FC04A331649C77A07B74E31@FMSMSX106.amr.corp.intel.com> Message-ID: <217BF3CF80E93540B3049F95A676F09D015F9BC0D9@cosmail01.lsi.com> Hi Paul, I just reviewed the patch. The patch looks good to us. Thanks Arpit From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Friday, October 05, 2012 3:24 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] MSID 0 share w/IO queue patch Thanks Alex. Rick or Arpit, have you guys had a chance to review yet? Thx Paul From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Friday, October 05, 2012 3:19 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: MSID 0 share w/IO queue patch Hi Paul, We are good with the patch. Thanks a lot for the effort. Regards, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Monday, October 01, 2012 4:03 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** MSID 0 share w/IO queue patch All- Here is the final patch for admin queue sharing and a few other misc cleanup items. Fully tested and I also reviewed w/Alex and Kwok F2F last week but will let Alex approve for himself. PW is intel123 Please let me know if there are any questions Thx Paul nvmeInit.c: - changes in loops and conditions to account for the number of cores now being the same as the number of vectors requested - removed unused element pMsiMsgTbl->CoreNum - removed unused element pMMT->CoreNum - in NVMeMsiMapCores(), now init the MsgId in the core table to the CQ number -1 (same as core #) - in DBG mode, track when learning is complete to support an assertion to make sure learning is always working - for the identify commands during the init state machine, we were DMA'ing directly into elements within devExt structures with no assurance of alignment. To address this I changed the target address of the xfer to use the driver state machine data buffer and copy it over on completion - NVMeAllocIoQueues(): fix to use an index that counts up through both core and NUMA loops (what Alex saw) instead of the inner loop. This val is used to index into the coreTable, the QueuId value will continue to behave as before and wrap at the number of queues nvmeIo.c: - two changes both wrapped in DBG, one to print PRP details and one to init the core # element in the srbExt used to make sure learning continues to do its job (check submitting core & completing core) nvmeStat.c - changes in loops and conditions to account for the number of cores now being the same as the number of vectors requested - init of the debug var used for learning mode nvmeStd.c - alloc one less entry for the MsgTable - in the completion routines (either DPC or ISR): -- switched the logic to check for the common case first (shared == FALSE) -- got rid of the learningMode var as we detect now based on startState as follows: If we're done with the init State machine: --> use the msg table to figure out which queue to look in Else if we're in learning mode: --> use the msgId + 1. Recall that when we alloc'd the queues we setup the CQ's such that QP 1 would use MSID0, QP 2 MSID 1, etc. Learning mode will loop through all of the QPs by walking the core table 0..number of cores. In the event that there are fewer QPs than cores because of an HBA limitation, this still works we just learn each queue more than once which does not hurt anything. Clearly when this happens things will not be optimal, they can't be without enough QPs, however we'll still fully utilize all of the available queue pairs - the loop has changed as the previous for loop didn't have the flexibility to check 2 non back-back queues. The QP that shared MSIX0 could be any of the other queues. I reworked the loops to be 2 do while loops and for an actual admin queue request we'll just check the admin queue, for the shared IO queue however we have to always check the admin queue as well. This logic is at the bottom of the loop and is fairly straightforward nvmeStd.h: - a few supporting changes - obvious Also made a few changes enar the end following review w/IDT: - replaced Rtl copy commands with storport copy commands - replaced Rtl zero mem commands with memset - added print at the end of learning mode to see updated mappings (initial mappings still print) ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Fri Oct 5 17:24:39 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Sat, 6 Oct 2012 00:24:39 +0000 Subject: [nvmewin] MSID 0 share w/IO queue patch In-Reply-To: <217BF3CF80E93540B3049F95A676F09D015F9BC0D9@cosmail01.lsi.com> References: <82C9F782B054C94B9FC04A331649C77A07B6E00E@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361DDB5A1A@corpmail2.na.ads.idt.com> <82C9F782B054C94B9FC04A331649C77A07B74E31@FMSMSX106.amr.corp.intel.com> <217BF3CF80E93540B3049F95A676F09D015F9BC0D9@cosmail01.lsi.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A07B755CC@FMSMSX106.amr.corp.intel.com> Thanks Arpit. I know there's at least one small patch waiting in the wings, they can be prepared following Ray's commit of this patch which will likely happen on Monday Thx Paul From: Patel, Arpit [mailto:Arpit.Patel at lsi.com] Sent: Friday, October 05, 2012 5:16 PM To: Luse, Paul E; Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: MSID 0 share w/IO queue patch Hi Paul, I just reviewed the patch. The patch looks good to us. Thanks Arpit From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Friday, October 05, 2012 3:24 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] MSID 0 share w/IO queue patch Thanks Alex. Rick or Arpit, have you guys had a chance to review yet? Thx Paul From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Friday, October 05, 2012 3:19 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: MSID 0 share w/IO queue patch Hi Paul, We are good with the patch. Thanks a lot for the effort. Regards, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Monday, October 01, 2012 4:03 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** MSID 0 share w/IO queue patch All- Here is the final patch for admin queue sharing and a few other misc cleanup items. Fully tested and I also reviewed w/Alex and Kwok F2F last week but will let Alex approve for himself. PW is intel123 Please let me know if there are any questions Thx Paul nvmeInit.c: - changes in loops and conditions to account for the number of cores now being the same as the number of vectors requested - removed unused element pMsiMsgTbl->CoreNum - removed unused element pMMT->CoreNum - in NVMeMsiMapCores(), now init the MsgId in the core table to the CQ number -1 (same as core #) - in DBG mode, track when learning is complete to support an assertion to make sure learning is always working - for the identify commands during the init state machine, we were DMA'ing directly into elements within devExt structures with no assurance of alignment. To address this I changed the target address of the xfer to use the driver state machine data buffer and copy it over on completion - NVMeAllocIoQueues(): fix to use an index that counts up through both core and NUMA loops (what Alex saw) instead of the inner loop. This val is used to index into the coreTable, the QueuId value will continue to behave as before and wrap at the number of queues nvmeIo.c: - two changes both wrapped in DBG, one to print PRP details and one to init the core # element in the srbExt used to make sure learning continues to do its job (check submitting core & completing core) nvmeStat.c - changes in loops and conditions to account for the number of cores now being the same as the number of vectors requested - init of the debug var used for learning mode nvmeStd.c - alloc one less entry for the MsgTable - in the completion routines (either DPC or ISR): -- switched the logic to check for the common case first (shared == FALSE) -- got rid of the learningMode var as we detect now based on startState as follows: If we're done with the init State machine: --> use the msg table to figure out which queue to look in Else if we're in learning mode: --> use the msgId + 1. Recall that when we alloc'd the queues we setup the CQ's such that QP 1 would use MSID0, QP 2 MSID 1, etc. Learning mode will loop through all of the QPs by walking the core table 0..number of cores. In the event that there are fewer QPs than cores because of an HBA limitation, this still works we just learn each queue more than once which does not hurt anything. Clearly when this happens things will not be optimal, they can't be without enough QPs, however we'll still fully utilize all of the available queue pairs - the loop has changed as the previous for loop didn't have the flexibility to check 2 non back-back queues. The QP that shared MSIX0 could be any of the other queues. I reworked the loops to be 2 do while loops and for an actual admin queue request we'll just check the admin queue, for the shared IO queue however we have to always check the admin queue as well. This logic is at the bottom of the loop and is fairly straightforward nvmeStd.h: - a few supporting changes - obvious Also made a few changes enar the end following review w/IDT: - replaced Rtl copy commands with storport copy commands - replaced Rtl zero mem commands with memset - added print at the end of learning mode to see updated mappings (initial mappings still print) ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From raymond.c.robles at intel.com Wed Oct 10 15:30:03 2012 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Wed, 10 Oct 2012 22:30:03 +0000 Subject: [nvmewin] NVMe Windows DB is LOCKED - Pushing latest patch from Paul Luse (Intel) - MSIx Vector 0 sharing fix Message-ID: <49158E750348AA499168FD41D88983601808B934@FMSMSX105.amr.corp.intel.com> Locking the NVMe Windows DB. Thanks, Ray [Description: cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles Attached Platform Storage Software Datacenter Software Division Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1756 bytes Desc: image001.png URL: From raymond.c.robles at intel.com Wed Oct 10 15:34:34 2012 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Wed, 10 Oct 2012 22:34:34 +0000 Subject: [nvmewin] NVMe Windows DB is UNLOCKED - Pushing latest patch from Paul Luse (Intel) - MSIx Vector 0 sharing fix Message-ID: <49158E750348AA499168FD41D88983601808B94D@FMSMSX105.amr.corp.intel.com> Latest patch by Intel (Paul Luse) has been pushed to the trunk. And, as always, I've created a tag for the latest push (msix_0_shared_vector_patch). Please make sure to update to get the latest code on the trunk and the new tag. If anyone has any questions, please feel free to contact me. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Wednesday, October 10, 2012 3:30 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] NVMe Windows DB is LOCKED - Pushing latest patch from Paul Luse (Intel) - MSIx Vector 0 sharing fix Locking the NVMe Windows DB. Thanks, Ray [Description: cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles Attached Platform Storage Software Datacenter Software Division Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1756 bytes Desc: image001.png URL: From kris.r.murray at intel.com Tue Oct 16 10:07:29 2012 From: kris.r.murray at intel.com (Murray, Kris R) Date: Tue, 16 Oct 2012 17:07:29 +0000 Subject: [nvmewin] Bug Fix Patch - Review Request Message-ID: <6B4557D9CF036C4E8F9D6C561818DABB0DD38680@FMSMSX106.amr.corp.intel.com> Hi all, The attached NVMe.zip file changes include the below fixes: * nvmeStd.c o Added a call to StorPortGetUncachedExtension to fix a checked OS assertion * nvmeSnti.c o Fixed SntiTranslateRead6 function to use the Read mask for the lba instead of the write mask o Fixed SntiTranslateWrite6 function to use the correct macro for getting 24 bits from the CDB using the correct offset * nvmeSntiTypes.h o Updated READ_6_CDB_LBA_MASK definition to match the one for write o Fixed WRITE_6_CDB_LBA_OFFSET from 0 to 1 The attached Results.zip file contains results from the test matrix below: Operating Systems: * Windows 7 * Windows 8 * Windows Server 2008 * Windows Server 2012 Tests: * IOMeter * SCSI Compliance * PCMark Please review the changes, feeling free to send me comments and questions. Thanks, ~Kris Murray -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Results.zip Type: application/x-zip-compressed Size: 246922 bytes Desc: Results.zip URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: NVMe.zip Type: application/x-zip-compressed Size: 167238 bytes Desc: NVMe.zip URL: From Alex.Chang at idt.com Thu Oct 18 16:45:16 2012 From: Alex.Chang at idt.com (Chang, Alex) Date: Thu, 18 Oct 2012 23:45:16 +0000 Subject: [nvmewin] Bug Fix Patch - Review Request In-Reply-To: <49158E750348AA499168FD41D88983603E14EBDF@FMSMSX105.amr.corp.intel.com> References: <6B4557D9CF036C4E8F9D6C561818DABB0DD38680@FMSMSX106.amr.corp.intel.com> <49158E750348AA499168FD41D88983603E14EBDF@FMSMSX105.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFBCDE9@corpmail1.na.ads.idt.com> Hi Ray, Sounds good to me. Thanks, Alex ________________________________ From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, October 18, 2012 4:43 PM To: NVMe Open Source Mailing List (mailto:nvmewin at lists.openfabrics.org); Chang, Alex; Kong, Kwok; Knoblaugh, Rick (Rick.Knoblaugh at lsi.com); Patel, Arpit (Arpit.Patel at lsi.com) Cc: Murray, Kris R; Luse, Paul E Subject: RE: Bug Fix Patch - Review Request IDT and LSI, Just so we have a timeframe on the review, how does feedback by next Thursday (October 25th) EOD sound? Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Murray, Kris R Sent: Tuesday, October 16, 2012 10:07 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Bug Fix Patch - Review Request Hi all, The attached NVMe.zip file changes include the below fixes: * nvmeStd.c o Added a call to StorPortGetUncachedExtension to fix a checked OS assertion * nvmeSnti.c o Fixed SntiTranslateRead6 function to use the Read mask for the lba instead of the write mask o Fixed SntiTranslateWrite6 function to use the correct macro for getting 24 bits from the CDB using the correct offset * nvmeSntiTypes.h o Updated READ_6_CDB_LBA_MASK definition to match the one for write o Fixed WRITE_6_CDB_LBA_OFFSET from 0 to 1 The attached Results.zip file contains results from the test matrix below: Operating Systems: * Windows 7 * Windows 8 * Windows Server 2008 * Windows Server 2012 Tests: * IOMeter * SCSI Compliance * PCMark Please review the changes, feeling free to send me comments and questions. Thanks, ~Kris Murray -------------- next part -------------- An HTML attachment was scrubbed... URL: From Rick.Knoblaugh at lsi.com Thu Oct 18 16:46:00 2012 From: Rick.Knoblaugh at lsi.com (Knoblaugh, Rick) Date: Thu, 18 Oct 2012 17:46:00 -0600 Subject: [nvmewin] Bug Fix Patch - Review Request In-Reply-To: <49158E750348AA499168FD41D88983603E14EBDF@FMSMSX105.amr.corp.intel.com> References: <6B4557D9CF036C4E8F9D6C561818DABB0DD38680@FMSMSX106.amr.corp.intel.com> <49158E750348AA499168FD41D88983603E14EBDF@FMSMSX105.amr.corp.intel.com> Message-ID: <4565AEA676113A449269C2F3A549520FCFE9F4E3@cosmail03.lsi.com> Hi Ray, Sounds good to me as well. I have been in touch with Kris on one question that I had. So, far, no issues with the changes. Thanks, -Rick From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, October 18, 2012 4:43 PM To: NVMe Open Source Mailing List (mailto:nvmewin at lists.openfabrics.org); 'Chang, Alex (Alex.Chang at idt.com)'; Kong, Kwok; Knoblaugh, Rick; Patel, Arpit Cc: Murray, Kris R; Luse, Paul E Subject: RE: Bug Fix Patch - Review Request IDT and LSI, Just so we have a timeframe on the review, how does feedback by next Thursday (October 25th) EOD sound? Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Murray, Kris R Sent: Tuesday, October 16, 2012 10:07 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Bug Fix Patch - Review Request Hi all, The attached NVMe.zip file changes include the below fixes: * nvmeStd.c o Added a call to StorPortGetUncachedExtension to fix a checked OS assertion * nvmeSnti.c o Fixed SntiTranslateRead6 function to use the Read mask for the lba instead of the write mask o Fixed SntiTranslateWrite6 function to use the correct macro for getting 24 bits from the CDB using the correct offset * nvmeSntiTypes.h o Updated READ_6_CDB_LBA_MASK definition to match the one for write o Fixed WRITE_6_CDB_LBA_OFFSET from 0 to 1 The attached Results.zip file contains results from the test matrix below: Operating Systems: * Windows 7 * Windows 8 * Windows Server 2008 * Windows Server 2012 Tests: * IOMeter * SCSI Compliance * PCMark Please review the changes, feeling free to send me comments and questions. Thanks, ~Kris Murray -------------- next part -------------- An HTML attachment was scrubbed... URL: From ram_sunee at yahoo.com Thu Oct 18 18:03:47 2012 From: ram_sunee at yahoo.com (Ramesh Mangamuri) Date: Thu, 18 Oct 2012 18:03:47 -0700 (PDT) Subject: [nvmewin] NVMe IO Generation using IOMETER In-Reply-To: <1350608181.64203.YahooMailClassic@web163904.mail.gq1.yahoo.com> Message-ID: <1350608627.4309.YahooMailClassic@web163903.mail.gq1.yahoo.com> All, I have noticed that in the NVMe windows driver release notes, IOMETER tool was mentioned for testing NVMe Driver.  Does the IOMETER need a modification to use with NVMe Driver or we can use it without any modifications.If no modification is needed,can someone please explain how the block IO calls from IOMETER were mapped/connected to NVMe Windows driver Stack to generate traffic using this driver ?     Best Regards, Ramesh   ******************************************************************************************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender.If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. *********************************************************************************************************************************************   -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Thu Oct 18 18:28:59 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Fri, 19 Oct 2012 01:28:59 +0000 Subject: [nvmewin] NVMe IO Generation using IOMETER In-Reply-To: <1350608627.4309.YahooMailClassic@web163903.mail.gq1.yahoo.com> References: <1350608181.64203.YahooMailClassic@web163904.mail.gq1.yahoo.com> <1350608627.4309.YahooMailClassic@web163903.mail.gq1.yahoo.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A07B9C31C@FMSMSX106.amr.corp.intel.com> No modification is needed. The NVMe driver surfaced namespaces as SCSI LUNs under storport so iometer can be used either available the physical disk or one can put a file system on the target as well. Thx Paul From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Ramesh Mangamuri Sent: Thursday, October 18, 2012 6:04 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] NVMe IO Generation using IOMETER All, I have noticed that in the NVMe windows driver release notes, IOMETER tool was mentioned for testing NVMe Driver. Does the IOMETER need a modification to use with NVMe Driver or we can use it without any modifications.If no modification is needed,can someone please explain how the block IO calls from IOMETER were mapped/connected to NVMe Windows driver Stack to generate traffic using this driver ? Best Regards, Ramesh ******************************************************************************************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender.If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. ********************************************************************************************************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From ram_sunee at yahoo.com Thu Oct 18 18:37:33 2012 From: ram_sunee at yahoo.com (Ramesh Mangamuri) Date: Thu, 18 Oct 2012 18:37:33 -0700 (PDT) Subject: [nvmewin] NVMe IO Generation using IOMETER In-Reply-To: <82C9F782B054C94B9FC04A331649C77A07B9C31C@FMSMSX106.amr.corp.intel.com> Message-ID: <1350610653.19603.YahooMailClassic@web163902.mail.gq1.yahoo.com> Paul,   Does this mean that NVMe driver do SCSI command to NVMe command translation, as of today , to facilitate using existing IO tools without modification ? Best Regards, Ramesh   ******************************************************************************************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender.If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. *********************************************************************************************************************************************   --- On Thu, 10/18/12, Luse, Paul E wrote: From: Luse, Paul E Subject: RE: [nvmewin] NVMe IO Generation using IOMETER To: "Ramesh Mangamuri" , "nvmewin at lists.openfabrics.org" Date: Thursday, October 18, 2012, 6:28 PM No modification is needed.  The NVMe driver surfaced namespaces as SCSI LUNs under storport so iometer can be used either available the physical disk or one can put a file system on the target as well.   Thx Paul   From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Ramesh Mangamuri Sent: Thursday, October 18, 2012 6:04 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] NVMe IO Generation using IOMETER   All, I have noticed that in the NVMe windows driver release notes, IOMETER tool was mentioned for testing NVMe Driver.  Does the IOMETER need a modification to use with NVMe Driver or we can use it without any modifications.If no modification is needed,can someone please explain how the block IO calls from IOMETER were mapped/connected to NVMe Windows driver Stack to generate traffic using this driver ?     Best Regards, Ramesh   ******************************************************************************************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender.If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. *********************************************************************************************************************************************     -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Thu Oct 18 19:04:19 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Fri, 19 Oct 2012 02:04:19 +0000 Subject: [nvmewin] NVMe IO Generation using IOMETER In-Reply-To: <1350610653.19603.YahooMailClassic@web163902.mail.gq1.yahoo.com> References: <82C9F782B054C94B9FC04A331649C77A07B9C31C@FMSMSX106.amr.corp.intel.com> <1350610653.19603.YahooMailClassic@web163902.mail.gq1.yahoo.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A07B9C388@FMSMSX106.amr.corp.intel.com> That is correct. A large (LOC) portion of the NVMe driver is handling SCSI?NVMe translation per the guidelines posted on the NVMe website at http://www.nvmexpress.org/index.php/download_file/view/69/1/ Thx Paul From: Ramesh Mangamuri [mailto:ram_sunee at yahoo.com] Sent: Thursday, October 18, 2012 6:38 PM To: nvmewin at lists.openfabrics.org; Luse, Paul E Subject: RE: [nvmewin] NVMe IO Generation using IOMETER Paul, Does this mean that NVMe driver do SCSI command to NVMe command translation, as of today , to facilitate using existing IO tools without modification ? Best Regards, Ramesh ******************************************************************************************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender.If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. ********************************************************************************************************************************************* --- On Thu, 10/18/12, Luse, Paul E > wrote: From: Luse, Paul E > Subject: RE: [nvmewin] NVMe IO Generation using IOMETER To: "Ramesh Mangamuri" >, "nvmewin at lists.openfabrics.org" > Date: Thursday, October 18, 2012, 6:28 PM No modification is needed. The NVMe driver surfaced namespaces as SCSI LUNs under storport so iometer can be used either available the physical disk or one can put a file system on the target as well. Thx Paul From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Ramesh Mangamuri Sent: Thursday, October 18, 2012 6:04 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] NVMe IO Generation using IOMETER All, I have noticed that in the NVMe windows driver release notes, IOMETER tool was mentioned for testing NVMe Driver. Does the IOMETER need a modification to use with NVMe Driver or we can use it without any modifications.If no modification is needed,can someone please explain how the block IO calls from IOMETER were mapped/connected to NVMe Windows driver Stack to generate traffic using this driver ? Best Regards, Ramesh ******************************************************************************************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender.If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. ********************************************************************************************************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Sun Oct 21 07:08:23 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Sun, 21 Oct 2012 14:08:23 +0000 Subject: [nvmewin] question in NVMeDetectPendingCmds Message-ID: <82C9F782B054C94B9FC04A331649C77A07B9FE51@FMSMSX106.amr.corp.intel.com> Rick- I *think* you might have put this in originally but am not positive, I'm currently fixing an issue in the recovery DPC routine (logic is wrong for determining the commands to complete on a reset) and I'm looking to re-use NVMeDetectPendingCmds() however I'm not sure why the function doesn't include looking at the admin queue. For purposes of power mgmt., which is this was added, I'd think we'd be just as concerned with outstanding admin commands as we would IO commands so wondering why admin was excluded? Thx Paul PS: I'll prepare a patch for this error recovery logic fix in the next week or so ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Rick.Knoblaugh at lsi.com Tue Oct 23 16:02:46 2012 From: Rick.Knoblaugh at lsi.com (Knoblaugh, Rick) Date: Tue, 23 Oct 2012 17:02:46 -0600 Subject: [nvmewin] question in NVMeDetectPendingCmds In-Reply-To: <82C9F782B054C94B9FC04A331649C77A07B9FE51@FMSMSX106.amr.corp.intel.com> References: <82C9F782B054C94B9FC04A331649C77A07B9FE51@FMSMSX106.amr.corp.intel.com> Message-ID: <4565AEA676113A449269C2F3A549520FCFE9FC55@cosmail03.lsi.com> Hi Paul, Yes, we did write that one. We wanted to check to ensure that no I/O commands were pending prior to shutting down. We weren't worried about Admin, as we would expect AERs to be always pending, and there probably wouldn't be much else - other than if there happened to be an AEN event and there was a subsequent Get Log Page pending. Actually, I suppose snti code may also issue something to Admin or potentially activity via pass through. It could be enhanced to look at Admin as well, but I think we'd have to skip over AERs, as they will "always" be present/pending. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Sunday, October 21, 2012 7:08 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] question in NVMeDetectPendingCmds Rick- I *think* you might have put this in originally but am not positive, I'm currently fixing an issue in the recovery DPC routine (logic is wrong for determining the commands to complete on a reset) and I'm looking to re-use NVMeDetectPendingCmds() however I'm not sure why the function doesn't include looking at the admin queue. For purposes of power mgmt., which is this was added, I'd think we'd be just as concerned with outstanding admin commands as we would IO commands so wondering why admin was excluded? Thx Paul PS: I'll prepare a patch for this error recovery logic fix in the next week or so ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Tue Oct 23 16:23:18 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Tue, 23 Oct 2012 23:23:18 +0000 Subject: [nvmewin] question in NVMeDetectPendingCmds In-Reply-To: <4565AEA676113A449269C2F3A549520FCFE9FC55@cosmail03.lsi.com> References: <82C9F782B054C94B9FC04A331649C77A07B9FE51@FMSMSX106.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FCFE9FC55@cosmail03.lsi.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A07BA5D27@FMSMSX106.amr.corp.intel.com> Thanks Rick, appreciate that. I probably won't have my patch ready this week after all, no big complexity or anything just time. I'll take the AERs into account through for sure Thx Paul From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Tuesday, October 23, 2012 4:03 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: question in NVMeDetectPendingCmds Hi Paul, Yes, we did write that one. We wanted to check to ensure that no I/O commands were pending prior to shutting down. We weren't worried about Admin, as we would expect AERs to be always pending, and there probably wouldn't be much else - other than if there happened to be an AEN event and there was a subsequent Get Log Page pending. Actually, I suppose snti code may also issue something to Admin or potentially activity via pass through. It could be enhanced to look at Admin as well, but I think we'd have to skip over AERs, as they will "always" be present/pending. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Sunday, October 21, 2012 7:08 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] question in NVMeDetectPendingCmds Rick- I *think* you might have put this in originally but am not positive, I'm currently fixing an issue in the recovery DPC routine (logic is wrong for determining the commands to complete on a reset) and I'm looking to re-use NVMeDetectPendingCmds() however I'm not sure why the function doesn't include looking at the admin queue. For purposes of power mgmt., which is this was added, I'd think we'd be just as concerned with outstanding admin commands as we would IO commands so wondering why admin was excluded? Thx Paul PS: I'll prepare a patch for this error recovery logic fix in the next week or so ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Rick.Knoblaugh at lsi.com Wed Oct 24 18:22:29 2012 From: Rick.Knoblaugh at lsi.com (Knoblaugh, Rick) Date: Wed, 24 Oct 2012 19:22:29 -0600 Subject: [nvmewin] Bug Fix Patch - Review Request In-Reply-To: <49158E750348AA499168FD41D88983603E14EBDF@FMSMSX105.amr.corp.intel.com> References: <6B4557D9CF036C4E8F9D6C561818DABB0DD38680@FMSMSX106.amr.corp.intel.com> <49158E750348AA499168FD41D88983603E14EBDF@FMSMSX105.amr.corp.intel.com> Message-ID: <4565AEA676113A449269C2F3A549520FCFE9FEDA@cosmail03.lsi.com> Hi Ray, We have reviewed and are good with these changes. Thanks, -Rick From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, October 18, 2012 4:43 PM To: NVMe Open Source Mailing List (mailto:nvmewin at lists.openfabrics.org); 'Chang, Alex (Alex.Chang at idt.com)'; Kong, Kwok; Knoblaugh, Rick; Patel, Arpit Cc: Murray, Kris R; Luse, Paul E Subject: RE: Bug Fix Patch - Review Request IDT and LSI, Just so we have a timeframe on the review, how does feedback by next Thursday (October 25th) EOD sound? Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Murray, Kris R Sent: Tuesday, October 16, 2012 10:07 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Bug Fix Patch - Review Request Hi all, The attached NVMe.zip file changes include the below fixes: * nvmeStd.c o Added a call to StorPortGetUncachedExtension to fix a checked OS assertion * nvmeSnti.c o Fixed SntiTranslateRead6 function to use the Read mask for the lba instead of the write mask o Fixed SntiTranslateWrite6 function to use the correct macro for getting 24 bits from the CDB using the correct offset * nvmeSntiTypes.h o Updated READ_6_CDB_LBA_MASK definition to match the one for write o Fixed WRITE_6_CDB_LBA_OFFSET from 0 to 1 The attached Results.zip file contains results from the test matrix below: Operating Systems: * Windows 7 * Windows 8 * Windows Server 2008 * Windows Server 2012 Tests: * IOMeter * SCSI Compliance * PCMark Please review the changes, feeling free to send me comments and questions. Thanks, ~Kris Murray -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Thu Oct 25 10:10:32 2012 From: Alex.Chang at idt.com (Chang, Alex) Date: Thu, 25 Oct 2012 17:10:32 +0000 Subject: [nvmewin] Bug Fix Patch - Review Request In-Reply-To: <6B4557D9CF036C4E8F9D6C561818DABB0DD38680@FMSMSX106.amr.corp.intel.com> References: <6B4557D9CF036C4E8F9D6C561818DABB0DD38680@FMSMSX106.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFBF3E7@corpmail1.na.ads.idt.com> Hi Kris, I have a quick question regarding StorPortGetUncachedExtension: The routine returns a pointer to the allocated buffer, should we validate the pointer before proceeding? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Murray, Kris R Sent: Tuesday, October 16, 2012 10:07 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Bug Fix Patch - Review Request Hi all, The attached NVMe.zip file changes include the below fixes: * nvmeStd.c o Added a call to StorPortGetUncachedExtension to fix a checked OS assertion * nvmeSnti.c o Fixed SntiTranslateRead6 function to use the Read mask for the lba instead of the write mask o Fixed SntiTranslateWrite6 function to use the correct macro for getting 24 bits from the CDB using the correct offset * nvmeSntiTypes.h o Updated READ_6_CDB_LBA_MASK definition to match the one for write o Fixed WRITE_6_CDB_LBA_OFFSET from 0 to 1 The attached Results.zip file contains results from the test matrix below: Operating Systems: * Windows 7 * Windows 8 * Windows Server 2008 * Windows Server 2012 Tests: * IOMeter * SCSI Compliance * PCMark Please review the changes, feeling free to send me comments and questions. Thanks, ~Kris Murray -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Thu Oct 25 10:32:12 2012 From: Alex.Chang at idt.com (Chang, Alex) Date: Thu, 25 Oct 2012 17:32:12 +0000 Subject: [nvmewin] Bug Fix Patch - Review Request In-Reply-To: <6B4557D9CF036C4E8F9D6C561818DABB0DD45232@FMSMSX106.amr.corp.intel.com> References: <6B4557D9CF036C4E8F9D6C561818DABB0DD38680@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFBF3E7@corpmail1.na.ads.idt.com> <6B4557D9CF036C4E8F9D6C561818DABB0DD45232@FMSMSX106.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFBF425@corpmail1.na.ads.idt.com> My concern is what if the allocation fails by any chance? Alex ________________________________ From: Murray, Kris R [mailto:kris.r.murray at intel.com] Sent: Thursday, October 25, 2012 10:23 AM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: Bug Fix Patch - Review Request Alex, Since we don't use the returned pointer I believe there is no need to validate it. The goal is to cause Storport to allocate a DMA adapter object. See the attached email from James Harris for more info. ~Kris From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, October 25, 2012 10:11 AM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Bug Fix Patch - Review Request Hi Kris, I have a quick question regarding StorPortGetUncachedExtension: The routine returns a pointer to the allocated buffer, should we validate the pointer before proceeding? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Murray, Kris R Sent: Tuesday, October 16, 2012 10:07 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Bug Fix Patch - Review Request Hi all, The attached NVMe.zip file changes include the below fixes: * nvmeStd.c o Added a call to StorPortGetUncachedExtension to fix a checked OS assertion * nvmeSnti.c o Fixed SntiTranslateRead6 function to use the Read mask for the lba instead of the write mask o Fixed SntiTranslateWrite6 function to use the correct macro for getting 24 bits from the CDB using the correct offset * nvmeSntiTypes.h o Updated READ_6_CDB_LBA_MASK definition to match the one for write o Fixed WRITE_6_CDB_LBA_OFFSET from 0 to 1 The attached Results.zip file contains results from the test matrix below: Operating Systems: * Windows 7 * Windows 8 * Windows Server 2008 * Windows Server 2012 Tests: * IOMeter * SCSI Compliance * PCMark Please review the changes, feeling free to send me comments and questions. Thanks, ~Kris Murray -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Thu Oct 25 10:52:47 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Thu, 25 Oct 2012 17:52:47 +0000 Subject: [nvmewin] Bug Fix Patch - Review Request In-Reply-To: <548C5470AAD9DA4A85D259B663190D361FFBF425@corpmail1.na.ads.idt.com> References: <6B4557D9CF036C4E8F9D6C561818DABB0DD38680@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFBF3E7@corpmail1.na.ads.idt.com> <6B4557D9CF036C4E8F9D6C561818DABB0DD45232@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFBF425@corpmail1.na.ads.idt.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A07BA8F56@FMSMSX106.amr.corp.intel.com> I think the answer is that we don't care. Msft suggested that we avoid causing assertions in the checked OS; that's all this does. We don't use the mem (and don't have to free it) so the only issue that would be present if it failed would be if someone happened to be running on a checked OS when that happened, they'd get an assert in storport just after find adapter and then they could ignore it and move on w/o any further problems.... From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Thursday, October 25, 2012 10:32 AM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Bug Fix Patch - Review Request My concern is what if the allocation fails by any chance? Alex ________________________________ From: Murray, Kris R [mailto:kris.r.murray at intel.com] Sent: Thursday, October 25, 2012 10:23 AM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: Bug Fix Patch - Review Request Alex, Since we don't use the returned pointer I believe there is no need to validate it. The goal is to cause Storport to allocate a DMA adapter object. See the attached email from James Harris for more info. ~Kris From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, October 25, 2012 10:11 AM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Bug Fix Patch - Review Request Hi Kris, I have a quick question regarding StorPortGetUncachedExtension: The routine returns a pointer to the allocated buffer, should we validate the pointer before proceeding? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Murray, Kris R Sent: Tuesday, October 16, 2012 10:07 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Bug Fix Patch - Review Request Hi all, The attached NVMe.zip file changes include the below fixes: * nvmeStd.c o Added a call to StorPortGetUncachedExtension to fix a checked OS assertion * nvmeSnti.c o Fixed SntiTranslateRead6 function to use the Read mask for the lba instead of the write mask o Fixed SntiTranslateWrite6 function to use the correct macro for getting 24 bits from the CDB using the correct offset * nvmeSntiTypes.h o Updated READ_6_CDB_LBA_MASK definition to match the one for write o Fixed WRITE_6_CDB_LBA_OFFSET from 0 to 1 The attached Results.zip file contains results from the test matrix below: Operating Systems: * Windows 7 * Windows 8 * Windows Server 2008 * Windows Server 2012 Tests: * IOMeter * SCSI Compliance * PCMark Please review the changes, feeling free to send me comments and questions. Thanks, ~Kris Murray -------------- next part -------------- An HTML attachment was scrubbed... URL: From kris.r.murray at intel.com Thu Oct 25 10:23:08 2012 From: kris.r.murray at intel.com (Murray, Kris R) Date: Thu, 25 Oct 2012 17:23:08 +0000 Subject: [nvmewin] Bug Fix Patch - Review Request In-Reply-To: <548C5470AAD9DA4A85D259B663190D361FFBF3E7@corpmail1.na.ads.idt.com> References: <6B4557D9CF036C4E8F9D6C561818DABB0DD38680@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFBF3E7@corpmail1.na.ads.idt.com> Message-ID: <6B4557D9CF036C4E8F9D6C561818DABB0DD45232@FMSMSX106.amr.corp.intel.com> Alex, Since we don't use the returned pointer I believe there is no need to validate it. The goal is to cause Storport to allocate a DMA adapter object. See the attached email from James Harris for more info. ~Kris From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, October 25, 2012 10:11 AM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Bug Fix Patch - Review Request Hi Kris, I have a quick question regarding StorPortGetUncachedExtension: The routine returns a pointer to the allocated buffer, should we validate the pointer before proceeding? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Murray, Kris R Sent: Tuesday, October 16, 2012 10:07 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Bug Fix Patch - Review Request Hi all, The attached NVMe.zip file changes include the below fixes: * nvmeStd.c o Added a call to StorPortGetUncachedExtension to fix a checked OS assertion * nvmeSnti.c o Fixed SntiTranslateRead6 function to use the Read mask for the lba instead of the write mask o Fixed SntiTranslateWrite6 function to use the correct macro for getting 24 bits from the CDB using the correct offset * nvmeSntiTypes.h o Updated READ_6_CDB_LBA_MASK definition to match the one for write o Fixed WRITE_6_CDB_LBA_OFFSET from 0 to 1 The attached Results.zip file contains results from the test matrix below: Operating Systems: * Windows 7 * Windows 8 * Windows Server 2008 * Windows Server 2012 Tests: * IOMeter * SCSI Compliance * PCMark Please review the changes, feeling free to send me comments and questions. Thanks, ~Kris Murray -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded message was scrubbed... From: "Harris, James R" Subject: Re: [nvmewin] Win8 assertion message Date: Fri, 16 Mar 2012 18:21:39 +0000 Size: 12672 URL: From Alex.Chang at idt.com Thu Oct 25 11:01:16 2012 From: Alex.Chang at idt.com (Chang, Alex) Date: Thu, 25 Oct 2012 18:01:16 +0000 Subject: [nvmewin] Bug Fix Patch - Review Request In-Reply-To: <82C9F782B054C94B9FC04A331649C77A07BA8F56@FMSMSX106.amr.corp.intel.com> References: <6B4557D9CF036C4E8F9D6C561818DABB0DD38680@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFBF3E7@corpmail1.na.ads.idt.com> <6B4557D9CF036C4E8F9D6C561818DABB0DD45232@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFBF425@corpmail1.na.ads.idt.com> <82C9F782B054C94B9FC04A331649C77A07BA8F56@FMSMSX106.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFBF450@corpmail1.na.ads.idt.com> Now, I get it. Thanks, Paul, for the background. I think we are good with the patch. Thanks for the effort, Kris. Alex ________________________________ From: Luse, Paul E [mailto:paul.e.luse at intel.com] Sent: Thursday, October 25, 2012 10:53 AM To: Chang, Alex; Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Bug Fix Patch - Review Request I think the answer is that we don't care. Msft suggested that we avoid causing assertions in the checked OS; that's all this does. We don't use the mem (and don't have to free it) so the only issue that would be present if it failed would be if someone happened to be running on a checked OS when that happened, they'd get an assert in storport just after find adapter and then they could ignore it and move on w/o any further problems.... From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Thursday, October 25, 2012 10:32 AM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Bug Fix Patch - Review Request My concern is what if the allocation fails by any chance? Alex ________________________________ From: Murray, Kris R [mailto:kris.r.murray at intel.com] Sent: Thursday, October 25, 2012 10:23 AM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: Bug Fix Patch - Review Request Alex, Since we don't use the returned pointer I believe there is no need to validate it. The goal is to cause Storport to allocate a DMA adapter object. See the attached email from James Harris for more info. ~Kris From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, October 25, 2012 10:11 AM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Bug Fix Patch - Review Request Hi Kris, I have a quick question regarding StorPortGetUncachedExtension: The routine returns a pointer to the allocated buffer, should we validate the pointer before proceeding? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Murray, Kris R Sent: Tuesday, October 16, 2012 10:07 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Bug Fix Patch - Review Request Hi all, The attached NVMe.zip file changes include the below fixes: * nvmeStd.c o Added a call to StorPortGetUncachedExtension to fix a checked OS assertion * nvmeSnti.c o Fixed SntiTranslateRead6 function to use the Read mask for the lba instead of the write mask o Fixed SntiTranslateWrite6 function to use the correct macro for getting 24 bits from the CDB using the correct offset * nvmeSntiTypes.h o Updated READ_6_CDB_LBA_MASK definition to match the one for write o Fixed WRITE_6_CDB_LBA_OFFSET from 0 to 1 The attached Results.zip file contains results from the test matrix below: Operating Systems: * Windows 7 * Windows 8 * Windows Server 2008 * Windows Server 2012 Tests: * IOMeter * SCSI Compliance * PCMark Please review the changes, feeling free to send me comments and questions. Thanks, ~Kris Murray -------------- next part -------------- An HTML attachment was scrubbed... URL: From raymond.c.robles at intel.com Thu Oct 25 12:20:19 2012 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Thu, 25 Oct 2012 19:20:19 +0000 Subject: [nvmewin] Bug Fix Patch - Review Request In-Reply-To: <4565AEA676113A449269C2F3A549520FCFE9FEDA@cosmail03.lsi.com> References: <6B4557D9CF036C4E8F9D6C561818DABB0DD38680@FMSMSX106.amr.corp.intel.com> <49158E750348AA499168FD41D88983603E14EBDF@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FCFE9FEDA@cosmail03.lsi.com> Message-ID: <49158E750348AA499168FD41D88983603E1510E6@FMSMSX105.amr.corp.intel.com> Thanks for reviewing Rick. -Ray From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Wednesday, October 24, 2012 6:22 PM To: Robles, Raymond C; NVMe Open Source Mailing List (mailto:nvmewin at lists.openfabrics.org); 'Chang, Alex (Alex.Chang at idt.com)'; Kong, Kwok; Patel, Arpit Cc: Murray, Kris R; Luse, Paul E Subject: RE: Bug Fix Patch - Review Request Hi Ray, We have reviewed and are good with these changes. Thanks, -Rick From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, October 18, 2012 4:43 PM To: NVMe Open Source Mailing List (mailto:nvmewin at lists.openfabrics.org); 'Chang, Alex (Alex.Chang at idt.com)'; Kong, Kwok; Knoblaugh, Rick; Patel, Arpit Cc: Murray, Kris R; Luse, Paul E Subject: RE: Bug Fix Patch - Review Request IDT and LSI, Just so we have a timeframe on the review, how does feedback by next Thursday (October 25th) EOD sound? Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Murray, Kris R Sent: Tuesday, October 16, 2012 10:07 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Bug Fix Patch - Review Request Hi all, The attached NVMe.zip file changes include the below fixes: * nvmeStd.c o Added a call to StorPortGetUncachedExtension to fix a checked OS assertion * nvmeSnti.c o Fixed SntiTranslateRead6 function to use the Read mask for the lba instead of the write mask o Fixed SntiTranslateWrite6 function to use the correct macro for getting 24 bits from the CDB using the correct offset * nvmeSntiTypes.h o Updated READ_6_CDB_LBA_MASK definition to match the one for write o Fixed WRITE_6_CDB_LBA_OFFSET from 0 to 1 The attached Results.zip file contains results from the test matrix below: Operating Systems: * Windows 7 * Windows 8 * Windows Server 2008 * Windows Server 2012 Tests: * IOMeter * SCSI Compliance * PCMark Please review the changes, feeling free to send me comments and questions. Thanks, ~Kris Murray -------------- next part -------------- An HTML attachment was scrubbed... URL: From raymond.c.robles at intel.com Thu Oct 25 12:28:12 2012 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Thu, 25 Oct 2012 19:28:12 +0000 Subject: [nvmewin] Bug Fix Patch - Review Request In-Reply-To: <548C5470AAD9DA4A85D259B663190D361FFBF450@corpmail1.na.ads.idt.com> References: <6B4557D9CF036C4E8F9D6C561818DABB0DD38680@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFBF3E7@corpmail1.na.ads.idt.com> <6B4557D9CF036C4E8F9D6C561818DABB0DD45232@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFBF425@corpmail1.na.ads.idt.com> <82C9F782B054C94B9FC04A331649C77A07BA8F56@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFBF450@corpmail1.na.ads.idt.com> Message-ID: <49158E750348AA499168FD41D88983603E151124@FMSMSX105.amr.corp.intel.com> Thanks for reviewing the patch Alex. I'll apply the patch today by EOD. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Thursday, October 25, 2012 11:01 AM To: Luse, Paul E; Murray, Kris R; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Bug Fix Patch - Review Request Now, I get it. Thanks, Paul, for the background. I think we are good with the patch. Thanks for the effort, Kris. Alex ________________________________ From: Luse, Paul E [mailto:paul.e.luse at intel.com] Sent: Thursday, October 25, 2012 10:53 AM To: Chang, Alex; Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Bug Fix Patch - Review Request I think the answer is that we don't care. Msft suggested that we avoid causing assertions in the checked OS; that's all this does. We don't use the mem (and don't have to free it) so the only issue that would be present if it failed would be if someone happened to be running on a checked OS when that happened, they'd get an assert in storport just after find adapter and then they could ignore it and move on w/o any further problems.... From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Thursday, October 25, 2012 10:32 AM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Bug Fix Patch - Review Request My concern is what if the allocation fails by any chance? Alex ________________________________ From: Murray, Kris R [mailto:kris.r.murray at intel.com] Sent: Thursday, October 25, 2012 10:23 AM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: Bug Fix Patch - Review Request Alex, Since we don't use the returned pointer I believe there is no need to validate it. The goal is to cause Storport to allocate a DMA adapter object. See the attached email from James Harris for more info. ~Kris From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, October 25, 2012 10:11 AM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Bug Fix Patch - Review Request Hi Kris, I have a quick question regarding StorPortGetUncachedExtension: The routine returns a pointer to the allocated buffer, should we validate the pointer before proceeding? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Murray, Kris R Sent: Tuesday, October 16, 2012 10:07 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Bug Fix Patch - Review Request Hi all, The attached NVMe.zip file changes include the below fixes: * nvmeStd.c o Added a call to StorPortGetUncachedExtension to fix a checked OS assertion * nvmeSnti.c o Fixed SntiTranslateRead6 function to use the Read mask for the lba instead of the write mask o Fixed SntiTranslateWrite6 function to use the correct macro for getting 24 bits from the CDB using the correct offset * nvmeSntiTypes.h o Updated READ_6_CDB_LBA_MASK definition to match the one for write o Fixed WRITE_6_CDB_LBA_OFFSET from 0 to 1 The attached Results.zip file contains results from the test matrix below: Operating Systems: * Windows 7 * Windows 8 * Windows Server 2008 * Windows Server 2012 Tests: * IOMeter * SCSI Compliance * PCMark Please review the changes, feeling free to send me comments and questions. Thanks, ~Kris Murray -------------- next part -------------- An HTML attachment was scrubbed... URL: From raymond.c.robles at intel.com Thu Oct 25 14:03:56 2012 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Thu, 25 Oct 2012 21:03:56 +0000 Subject: [nvmewin] NVMe Windows Repo is LOCKED - Pushing latest patch from Kris Murray (Intel) - Win 8 Checked OS Assertion Message-ID: <49158E750348AA499168FD41D88983603E15122C@FMSMSX105.amr.corp.intel.com> Locking the NVMe Windows repo. Please refrain from updating until push is complete. Thanks, Ray [Description: cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles Attached Platform Storage Software Datacenter Software Division Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1756 bytes Desc: image001.png URL: From raymond.c.robles at intel.com Thu Oct 25 14:36:04 2012 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Thu, 25 Oct 2012 21:36:04 +0000 Subject: [nvmewin] NVMe Windows Repo is UNLOCKED - Pushing latest patch from Kris Murray (Intel) - Win 8 Checked OS Assertion Message-ID: <49158E750348AA499168FD41D88983603E1512E3@FMSMSX105.amr.corp.intel.com> Latest patch by Intel (Kris Murray) has been pushed to the trunk. I've also created the tag Win_8_Checked_OS_Assert_Fix as a snapshot for this patch. Please make sure to update to get the latest code on the trunk and the new tag. If anyone has any questions, please feel free to contact me. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, October 25, 2012 2:04 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] NVMe Windows Repo is LOCKED - Pushing latest patch from Kris Murray (Intel) - Win 8 Checked OS Assertion Locking the NVMe Windows repo. Please refrain from updating until push is complete. Thanks, Ray [Description: cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles Attached Platform Storage Software Datacenter Software Division Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1756 bytes Desc: image001.png URL: