From kris.r.murray at intel.com Mon Jun 4 11:15:11 2012 From: kris.r.murray at intel.com (Murray, Kris R) Date: Mon, 4 Jun 2012 18:15:11 +0000 Subject: [nvmewin] ***UNCHECKED*** numberOfPrpEntries patch for review Message-ID: <6B4557D9CF036C4E8F9D6C561818DABB0DCD641D@FMSMSX106.amr.corp.intel.com> All, Summary: I found a bug in the ProcessIo step for copying the PRP list. From the SNTI code, the variable numberOfPrpEntries in the SRB Extension was built as the total number of PRPs for the NVMe command. However, the code to copy over the PRP list uses this variable unaltered. This creates a bug where one too many PRP entries are copied. This bug hasn't surfaced yet because creating an NVMe command with the maximum number of PRP entries in the list hasn't been tested yet. See NVMe_PRP_fix.zip for source. Password: NVMe1234 Changes: nvmeStd.h : - The numberofPrpEntries variable in the SRB Extension is updated with a comment that clarifies that it holds the total number of PRPs, not just the PRP entries in the list nvmeIo.c: - Instead of checking for a valid entry 0 in the list, the number of entries is checked - The amount of memory to copy is decreased by the size of 1 entry to account for the PRP that is in PRP1 of the command. Code Sample: nvmeStd.h /* Temp PRP List */ UINT64 prpList[MAX_TX_SIZE / PAGE_SIZE]; /* Keep track of the total number of PRPs */ UINT32 numberOfPrpEntries; nvmeIo.c if (pSrbExtension->numberOfPrpEntries > 2) { pNvmeCmd->PRP2 = pCmdInfo->prpListPhyAddr.QuadPart; /* Copy the PRP list pointed to by PRP2.... * Size of the copy is total num of PRPs -1 because * PRP1 is not in the PRP list pointed to by PRP2 */ StorPortMoveMemory((PVOID)pCmdInfo->pPRPList, (PVOID)&pSrbExtension->prpList[0], ((pSrbExtension->numberOfPrpEntries - 1) * sizeof(UINT64))); } Testing (Logs attached): - IOMeter: PASS - See result.csv - PCMark7: PASS - See NVMe.pcmark-7-result - SCSI Compliance 2.0: 77 PASS, 36 WARN, 2 FAIL - See scsi_comp.txt - SD Stress: PASS - See SDSTRESS.LOG Thanks, Kris Murray -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: results.csv Type: application/octet-stream Size: 351950 bytes Desc: results.csv URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: NVMe.pcmark-7-result Type: application/octet-stream Size: 40070 bytes Desc: NVMe.pcmark-7-result URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SDSTRESS.LOG Type: application/octet-stream Size: 1245162 bytes Desc: SDSTRESS.LOG URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: scsi_comp.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: NVMe_PRP_fix.zip Type: application/x-zip-compressed Size: 151380 bytes Desc: NVMe_PRP_fix.zip URL: From paul.e.luse at intel.com Mon Jun 4 12:28:49 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Mon, 4 Jun 2012 19:28:49 +0000 Subject: [nvmewin] numberOfPrpEntries patch for review In-Reply-To: <6B4557D9CF036C4E8F9D6C561818DABB0DCD641D@FMSMSX106.amr.corp.intel.com> References: <6B4557D9CF036C4E8F9D6C561818DABB0DCD641D@FMSMSX106.amr.corp.intel.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A02535E4F@FMSMSX106.amr.corp.intel.com> Intel is cool w/this (obviously) J From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Murray, Kris R Sent: Monday, June 04, 2012 11:15 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** numberOfPrpEntries patch for review All, Summary: I found a bug in the ProcessIo step for copying the PRP list. From the SNTI code, the variable numberOfPrpEntries in the SRB Extension was built as the total number of PRPs for the NVMe command. However, the code to copy over the PRP list uses this variable unaltered. This creates a bug where one too many PRP entries are copied. This bug hasn't surfaced yet because creating an NVMe command with the maximum number of PRP entries in the list hasn't been tested yet. See NVMe_PRP_fix.zip for source. Password: NVMe1234 Changes: nvmeStd.h : - The numberofPrpEntries variable in the SRB Extension is updated with a comment that clarifies that it holds the total number of PRPs, not just the PRP entries in the list nvmeIo.c: - Instead of checking for a valid entry 0 in the list, the number of entries is checked - The amount of memory to copy is decreased by the size of 1 entry to account for the PRP that is in PRP1 of the command. Code Sample: nvmeStd.h /* Temp PRP List */ UINT64 prpList[MAX_TX_SIZE / PAGE_SIZE]; /* Keep track of the total number of PRPs */ UINT32 numberOfPrpEntries; nvmeIo.c if (pSrbExtension->numberOfPrpEntries > 2) { pNvmeCmd->PRP2 = pCmdInfo->prpListPhyAddr.QuadPart; /* Copy the PRP list pointed to by PRP2.... * Size of the copy is total num of PRPs -1 because * PRP1 is not in the PRP list pointed to by PRP2 */ StorPortMoveMemory((PVOID)pCmdInfo->pPRPList, (PVOID)&pSrbExtension->prpList[0], ((pSrbExtension->numberOfPrpEntries - 1) * sizeof(UINT64))); } Testing (Logs attached): - IOMeter: PASS - See result.csv - PCMark7: PASS - See NVMe.pcmark-7-result - SCSI Compliance 2.0: 77 PASS, 36 WARN, 2 FAIL - See scsi_comp.txt - SD Stress: PASS - See SDSTRESS.LOG Thanks, Kris Murray -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Mon Jun 4 17:00:38 2012 From: Alex.Chang at idt.com (Chang, Alex) Date: Tue, 5 Jun 2012 00:00:38 +0000 Subject: [nvmewin] numberOfPrpEntries patch for review In-Reply-To: <6B4557D9CF036C4E8F9D6C561818DABB0DCD641D@FMSMSX106.amr.corp.intel.com> References: <6B4557D9CF036C4E8F9D6C561818DABB0DCD641D@FMSMSX106.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D3601AB9E@corpmail1.na.ads.idt.com> IDT is fine with the fix. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Murray, Kris R Sent: Monday, June 04, 2012 11:15 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** numberOfPrpEntries patch for review All, Summary: I found a bug in the ProcessIo step for copying the PRP list. From the SNTI code, the variable numberOfPrpEntries in the SRB Extension was built as the total number of PRPs for the NVMe command. However, the code to copy over the PRP list uses this variable unaltered. This creates a bug where one too many PRP entries are copied. This bug hasn't surfaced yet because creating an NVMe command with the maximum number of PRP entries in the list hasn't been tested yet. See NVMe_PRP_fix.zip for source. Password: NVMe1234 Changes: nvmeStd.h : - The numberofPrpEntries variable in the SRB Extension is updated with a comment that clarifies that it holds the total number of PRPs, not just the PRP entries in the list nvmeIo.c: - Instead of checking for a valid entry 0 in the list, the number of entries is checked - The amount of memory to copy is decreased by the size of 1 entry to account for the PRP that is in PRP1 of the command. Code Sample: nvmeStd.h /* Temp PRP List */ UINT64 prpList[MAX_TX_SIZE / PAGE_SIZE]; /* Keep track of the total number of PRPs */ UINT32 numberOfPrpEntries; nvmeIo.c if (pSrbExtension->numberOfPrpEntries > 2) { pNvmeCmd->PRP2 = pCmdInfo->prpListPhyAddr.QuadPart; /* Copy the PRP list pointed to by PRP2.... * Size of the copy is total num of PRPs -1 because * PRP1 is not in the PRP list pointed to by PRP2 */ StorPortMoveMemory((PVOID)pCmdInfo->pPRPList, (PVOID)&pSrbExtension->prpList[0], ((pSrbExtension->numberOfPrpEntries - 1) * sizeof(UINT64))); } Testing (Logs attached): - IOMeter: PASS - See result.csv - PCMark7: PASS - See NVMe.pcmark-7-result - SCSI Compliance 2.0: 77 PASS, 36 WARN, 2 FAIL - See scsi_comp.txt - SD Stress: PASS - See SDSTRESS.LOG Thanks, Kris Murray -------------- next part -------------- An HTML attachment was scrubbed... URL: From Rick.Knoblaugh at lsi.com Mon Jun 4 18:28:42 2012 From: Rick.Knoblaugh at lsi.com (Knoblaugh, Rick) Date: Mon, 4 Jun 2012 19:28:42 -0600 Subject: [nvmewin] numberOfPrpEntries patch for review In-Reply-To: <548C5470AAD9DA4A85D259B663190D3601AB9E@corpmail1.na.ads.idt.com> References: <6B4557D9CF036C4E8F9D6C561818DABB0DCD641D@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D3601AB9E@corpmail1.na.ads.idt.com> Message-ID: <4565AEA676113A449269C2F3A549520FB637C840@cosmail03.lsi.com> LSI is good with it as well. Thanks, -RIck From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Monday, June 04, 2012 5:01 PM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] numberOfPrpEntries patch for review IDT is fine with the fix. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Murray, Kris R Sent: Monday, June 04, 2012 11:15 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** numberOfPrpEntries patch for review All, Summary: I found a bug in the ProcessIo step for copying the PRP list. From the SNTI code, the variable numberOfPrpEntries in the SRB Extension was built as the total number of PRPs for the NVMe command. However, the code to copy over the PRP list uses this variable unaltered. This creates a bug where one too many PRP entries are copied. This bug hasn't surfaced yet because creating an NVMe command with the maximum number of PRP entries in the list hasn't been tested yet. See NVMe_PRP_fix.zip for source. Password: NVMe1234 Changes: nvmeStd.h : - The numberofPrpEntries variable in the SRB Extension is updated with a comment that clarifies that it holds the total number of PRPs, not just the PRP entries in the list nvmeIo.c: - Instead of checking for a valid entry 0 in the list, the number of entries is checked - The amount of memory to copy is decreased by the size of 1 entry to account for the PRP that is in PRP1 of the command. Code Sample: nvmeStd.h /* Temp PRP List */ UINT64 prpList[MAX_TX_SIZE / PAGE_SIZE]; /* Keep track of the total number of PRPs */ UINT32 numberOfPrpEntries; nvmeIo.c if (pSrbExtension->numberOfPrpEntries > 2) { pNvmeCmd->PRP2 = pCmdInfo->prpListPhyAddr.QuadPart; /* Copy the PRP list pointed to by PRP2.... * Size of the copy is total num of PRPs -1 because * PRP1 is not in the PRP list pointed to by PRP2 */ StorPortMoveMemory((PVOID)pCmdInfo->pPRPList, (PVOID)&pSrbExtension->prpList[0], ((pSrbExtension->numberOfPrpEntries - 1) * sizeof(UINT64))); } Testing (Logs attached): - IOMeter: PASS - See result.csv - PCMark7: PASS - See NVMe.pcmark-7-result - SCSI Compliance 2.0: 77 PASS, 36 WARN, 2 FAIL - See scsi_comp.txt - SD Stress: PASS - See SDSTRESS.LOG Thanks, Kris Murray -------------- next part -------------- An HTML attachment was scrubbed... URL: From raymond.c.robles at intel.com Mon Jun 4 22:44:38 2012 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Tue, 5 Jun 2012 05:44:38 +0000 Subject: [nvmewin] numberOfPrpEntries patch for review In-Reply-To: <4565AEA676113A449269C2F3A549520FB637C840@cosmail03.lsi.com> References: <6B4557D9CF036C4E8F9D6C561818DABB0DCD641D@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D3601AB9E@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520FB637C840@cosmail03.lsi.com> Message-ID: <49158E750348AA499168FD41D88983600F1BB35A@FMSMSX105.amr.corp.intel.com> Thanks Rick and Alex! I'll get this change merged in to the OFA baseline this week. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Monday, June 04, 2012 6:29 PM To: Chang, Alex; Murray, Kris R; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] numberOfPrpEntries patch for review LSI is good with it as well. Thanks, -RIck From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Monday, June 04, 2012 5:01 PM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] numberOfPrpEntries patch for review IDT is fine with the fix. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Murray, Kris R Sent: Monday, June 04, 2012 11:15 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** numberOfPrpEntries patch for review All, Summary: I found a bug in the ProcessIo step for copying the PRP list. From the SNTI code, the variable numberOfPrpEntries in the SRB Extension was built as the total number of PRPs for the NVMe command. However, the code to copy over the PRP list uses this variable unaltered. This creates a bug where one too many PRP entries are copied. This bug hasn't surfaced yet because creating an NVMe command with the maximum number of PRP entries in the list hasn't been tested yet. See NVMe_PRP_fix.zip for source. Password: NVMe1234 Changes: nvmeStd.h : - The numberofPrpEntries variable in the SRB Extension is updated with a comment that clarifies that it holds the total number of PRPs, not just the PRP entries in the list nvmeIo.c: - Instead of checking for a valid entry 0 in the list, the number of entries is checked - The amount of memory to copy is decreased by the size of 1 entry to account for the PRP that is in PRP1 of the command. Code Sample: nvmeStd.h /* Temp PRP List */ UINT64 prpList[MAX_TX_SIZE / PAGE_SIZE]; /* Keep track of the total number of PRPs */ UINT32 numberOfPrpEntries; nvmeIo.c if (pSrbExtension->numberOfPrpEntries > 2) { pNvmeCmd->PRP2 = pCmdInfo->prpListPhyAddr.QuadPart; /* Copy the PRP list pointed to by PRP2.... * Size of the copy is total num of PRPs -1 because * PRP1 is not in the PRP list pointed to by PRP2 */ StorPortMoveMemory((PVOID)pCmdInfo->pPRPList, (PVOID)&pSrbExtension->prpList[0], ((pSrbExtension->numberOfPrpEntries - 1) * sizeof(UINT64))); } Testing (Logs attached): - IOMeter: PASS - See result.csv - PCMark7: PASS - See NVMe.pcmark-7-result - SCSI Compliance 2.0: 77 PASS, 36 WARN, 2 FAIL - See scsi_comp.txt - SD Stress: PASS - See SDSTRESS.LOG Thanks, Kris Murray -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.r.harris at intel.com Wed Jun 6 15:01:57 2012 From: james.r.harris at intel.com (Harris, James R) Date: Wed, 6 Jun 2012 22:01:57 +0000 Subject: [nvmewin] Using StorPortAllocatePool in crashdump/hibernate context Message-ID: Hi all, I noticed that there are a few places in crashdump/hibernate context where StorPortAllocatePool() is being called. NVMeInitialize(), when ntldrDump == FALSE, is where I saw a few of these calls, but there may be others. WDK says this can only be called at <= DISPATCH, but crashdump/hibernate mode is all run at DIRQL. I've seen StorPortAllocatePool() hang during crash/hiber mode when testing other Storport drivers I've worked on in the past. It may be helpful to put an assert in the NVMeAllocatePool routine to check IRQL to work through this once the driver starts getting used more for boot testing. This should probably be fixed to use space in the DeviceExtension - crash/hiber mode can request up to a ~60KB extension. If more space is needed, there are a couple of alternative methods (DumpRegion/RequestedDumpBufferSize, or global data buffers) to get more space, but fitting in the DeviceExtension is cleanest and least troublesome. Regards, -Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.p.freyensee at intel.com Thu Jun 7 16:39:15 2012 From: james.p.freyensee at intel.com (Freyensee, James P) Date: Thu, 7 Jun 2012 23:39:15 +0000 Subject: [nvmewin] the working order of faking NVMIdentify() Message-ID: <2D98093777D3FD46A36253F35FE9D69346B65D7E@ORSMSX101.amr.corp.intel.com> Hi, I am a little confused on how the driver fakes returning an NVMIdentify value I was hoping someone could tell me how it's doing it? I see in NVMeProcessIoctl() there is a case for ADMIN_IDENTIFY. But there is nothing ordinary being called that tips me into the driver handling supplying data for an NVMIdentify. I see it happening in the initialization module, in NVMeInitCallback(), which is eventually called by NVMeRunning(). The reason I ask this is I may want to do something similar to the NVMe GET LOG PAGE command, return a set value every single time for a debugging case. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Sun Jun 10 10:21:05 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Sun, 10 Jun 2012 17:21:05 +0000 Subject: [nvmewin] the working order of faking NVMIdentify() In-Reply-To: <2D98093777D3FD46A36253F35FE9D69346B65D7E@ORSMSX101.amr.corp.intel.com> References: <2D98093777D3FD46A36253F35FE9D69346B65D7E@ORSMSX101.amr.corp.intel.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A02539A20@FMSMSX106.amr.corp.intel.com> Not sure if you got a response to this or not but it only does that for Chatham so none of this is really relevant for anyone else. Chatham and Chatham2 do things differently, if your device cannot accept the cmd you want to send then you of course have to intercept it on the submission side as Chatham does. If it can handle the command but you want different data you intercept it on the return side like we do with Chatham2. From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Freyensee, James P Sent: Thursday, June 07, 2012 4:39 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] the working order of faking NVMIdentify() Hi, I am a little confused on how the driver fakes returning an NVMIdentify value I was hoping someone could tell me how it's doing it? I see in NVMeProcessIoctl() there is a case for ADMIN_IDENTIFY. But there is nothing ordinary being called that tips me into the driver handling supplying data for an NVMIdentify. I see it happening in the initialization module, in NVMeInitCallback(), which is eventually called by NVMeRunning(). The reason I ask this is I may want to do something similar to the NVMe GET LOG PAGE command, return a set value every single time for a debugging case. The INT side will be in NVMeInitCallback() which decodes the command being completed within the routine (it's a shared completion routine for all init commands). Look at case NVMeWaitOnIdentifyCtrl: and you will see where Chatham2 jumps in and hardcodes the response data via HardCodeChatham2Data(). We don't do any log page commands as part of init so you will have to slip it into one of the existing states (like where we do all the set/get features) or make a new state. If its debug code that you aren't going to contribute then you can whatever you like, if you think there is value in adding plumbing for log pages at init then please add a whole new state handler. Give me a buzz if you want a quick tutorial on how to do that. If on the submissions side, look at NVMeRunningWaitOnIdentifyCtrl() and you'll see where I hardcode all of the ID data right there in line and then at the very end there I setup the next state to call and call it via the arbiter function. -Paul Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From raymond.c.robles at intel.com Sun Jun 17 23:54:32 2012 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Mon, 18 Jun 2012 06:54:32 +0000 Subject: [nvmewin] DB is locked - Merging changes for Number of PRP List entries bug fix Message-ID: <49158E750348AA499168FD41D88983600F1CD01D@FMSMSX105.amr.corp.intel.com> Thanks, Ray [Description: Description: Description: cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles Platform Solutions Group | DCSG | IAG 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 Mon Jun 18 00:54:46 2012 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Mon, 18 Jun 2012 07:54:46 +0000 Subject: [nvmewin] DB is Unlocked - Merging changes for Number of PRP List entries bug fix - NO CHANGES MADE Message-ID: <49158E750348AA499168FD41D88983600F1CD03C@FMSMSX105.amr.corp.intel.com> Working out issues with new server. Will check in this fix in a day or two. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Sunday, June 17, 2012 11:55 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] DB is locked - Merging changes for Number of PRP List entries bug fix Thanks, Ray [Description: Description: Description: cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles Platform Solutions Group | DCSG | IAG 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 paul.e.luse at intel.com Mon Jun 18 12:05:19 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Mon, 18 Jun 2012 19:05:19 +0000 Subject: [nvmewin] a few defects... Message-ID: <82C9F782B054C94B9FC04A331649C77A0255315E@FMSMSX106.amr.corp.intel.com> Just an FYI in case anyone is running into these. We have fixes for them and will work on getting a patch in either this week or next (want to wait til Ray is able to get the last one applied following the server change). - report luns still had an issue in the format of the response data, the actual LUN # was 1 byte off so if you really had multiple LUNS, storport wouldn't scan them - the NVME_CC_IOSQES and CQ definitions in nvmereg.h were wrong (should be 6 and 4 respectively) - double buffering code needed a few tweaks if anyone tried to enable that they would have found out (tweaks based on changes made since it was originally coded) - small bug in get/set features portion of init state machine where we don't do both set & get on all LUNs ____________________________________ 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 Mon Jun 18 12:21:06 2012 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Mon, 18 Jun 2012 19:21:06 +0000 Subject: [nvmewin] DB is LOCKED - Committing PRP list num entries bug fix Message-ID: <49158E750348AA499168FD41D88983600F1CD2B1@FMSMSX105.amr.corp.intel.com> [Description: cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles Platform Solutions Group | DCSG | IAG 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 Mon Jun 18 12:37:38 2012 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Mon, 18 Jun 2012 19:37:38 +0000 Subject: [nvmewin] DB is UNLOCKED - Committing PRP list num entries bug fix Message-ID: <49158E750348AA499168FD41D88983600F1CD2F7@FMSMSX105.amr.corp.intel.com> Changes have been successfully checked in. As always I also created a new tag for this fix and the trunk is the latest and greatest. Here is the summary of changes for this fix again. Please make sure to update your copies of the repository. nvmeStd.h : - The numberOfPrpEntries variable in the SRB Extension is updated with a comment that clarifies that it holds the total number of PRPs, not just the PRP entries in the list nvmeIo.c: - Instead of checking for a valid entry 0 in the list, the number of entries is checked - The amount of memory to copy is decreased by the size of 1 entry to account for the PRP that is in PRP1 of the command. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, June 18, 2012 12:21 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] DB is LOCKED - Committing PRP list num entries bug fix [Description: cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles Platform Solutions Group | DCSG | IAG 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 paul.e.luse at intel.com Wed Jun 20 07:09:34 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Wed, 20 Jun 2012 14:09:34 +0000 Subject: [nvmewin] Q4 release and contributions Message-ID: <82C9F782B054C94B9FC04A331649C77A0255532B@FMSMSX106.amr.corp.intel.com> All- I've got a request for the community... thus far Intel has been making most of the contributions since we went open source and I'd like to encourage everyone to push your changes back to the base so we realize the benefits of being open source. I've got another patch that I'll be submitting (mentioned before) with some bug fixes plus I added support for DB strides. I'm hoping someone will sign up for the following 2 feature investigations/additions. One is changes for storport in Win8, many of the items won't be needed right away but I'd like someone to sign up to investigate and implement the things that make sense for the open source driver (setting a good example for optimizations in Win8). Secondly is support for 1.0c, I've listed the doc deltas and am looking for an owner to further investigate each item and implement the changes. Alex/Rick/Arpit... anyone who has not contributed? Can you look at picking these things up? Timeframe is to have them in and tested before the end of this quarter so we're ready for our Q5 release. Thanks Paul STORPORT FOR WIN8 http://msdn.microsoft.com/en-us/library/windows/hardware/hh451200%28v=vs.85%29.aspx 1.0c SUPPORT [ ]Invalid Doorbell Write handling - page 41 [ ]Need to make sure our IOCTL pipe checks vendor unique command format - page 44 [ ]Need to support "Firmware Application Requires Conventional Reset" response to Firmware Activate - page 49, page 62 [ ]Only abort asynchronous event requests when the controller is reset (not on queue deletion) - page 56 [ ]Firmware image download field NUMD is now 0s based value - page 63 [ ]Get Log Page field NUMD is 0's based - page 65 [ ]Get Log Page field Status Field, bit 00 is Phase Tag - page 66 [ ]Identify Controller - new fields "Admin Vendor Specific Command Configuration" and "NVM Vendor Specific Command Configuration" - page 71 & 73 [ ]Security Receive - length field changed from 16 to 32 bits, expanded into LSBs - page 87 [ ]Security Send - length field changed from 16 to 32 bits, expanded into LSBs - page 89 [ ]Definition added for deallocated metadata return, all 1's - page 97 ____________________________________ 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 Wed Jun 20 14:22:03 2012 From: Alex.Chang at idt.com (Chang, Alex) Date: Wed, 20 Jun 2012 21:22:03 +0000 Subject: [nvmewin] Q4 release and contributions In-Reply-To: <82C9F782B054C94B9FC04A331649C77A0255532B@FMSMSX106.amr.corp.intel.com> References: <82C9F782B054C94B9FC04A331649C77A0255532B@FMSMSX106.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D3601B49D@corpmail1.na.ads.idt.com> Hi Paul, I will make changes to comply with 1.0c for the Q5 release. In addition, I had made some changes to fix INTx and Power Management related issues, which will be included in the release. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Wednesday, June 20, 2012 7:10 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Q4 release and contributions All- I've got a request for the community... thus far Intel has been making most of the contributions since we went open source and I'd like to encourage everyone to push your changes back to the base so we realize the benefits of being open source. I've got another patch that I'll be submitting (mentioned before) with some bug fixes plus I added support for DB strides. I'm hoping someone will sign up for the following 2 feature investigations/additions. One is changes for storport in Win8, many of the items won't be needed right away but I'd like someone to sign up to investigate and implement the things that make sense for the open source driver (setting a good example for optimizations in Win8). Secondly is support for 1.0c, I've listed the doc deltas and am looking for an owner to further investigate each item and implement the changes. Alex/Rick/Arpit... anyone who has not contributed? Can you look at picking these things up? Timeframe is to have them in and tested before the end of this quarter so we're ready for our Q5 release. Thanks Paul STORPORT FOR WIN8 http://msdn.microsoft.com/en-us/library/windows/hardware/hh451200%28v=vs.85%29.aspx 1.0c SUPPORT [ ]Invalid Doorbell Write handling - page 41 [ ]Need to make sure our IOCTL pipe checks vendor unique command format - page 44 [ ]Need to support "Firmware Application Requires Conventional Reset" response to Firmware Activate - page 49, page 62 [ ]Only abort asynchronous event requests when the controller is reset (not on queue deletion) - page 56 [ ]Firmware image download field NUMD is now 0s based value - page 63 [ ]Get Log Page field NUMD is 0's based - page 65 [ ]Get Log Page field Status Field, bit 00 is Phase Tag - page 66 [ ]Identify Controller - new fields "Admin Vendor Specific Command Configuration" and "NVM Vendor Specific Command Configuration" - page 71 & 73 [ ]Security Receive - length field changed from 16 to 32 bits, expanded into LSBs - page 87 [ ]Security Send - length field changed from 16 to 32 bits, expanded into LSBs - page 89 [ ]Definition added for deallocated metadata return, all 1's - page 97 ____________________________________ 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 Thu Jun 21 11:01:16 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Thu, 21 Jun 2012 18:01:16 +0000 Subject: [nvmewin] Q4 release and contributions In-Reply-To: <548C5470AAD9DA4A85D259B663190D3601B49D@corpmail1.na.ads.idt.com> References: <82C9F782B054C94B9FC04A331649C77A0255532B@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D3601B49D@corpmail1.na.ads.idt.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A0255C35B@FMSMSX106.amr.corp.intel.com> Excellent Alex, thanks! From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Wednesday, June 20, 2012 2:22 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: Q4 release and contributions Hi Paul, I will make changes to comply with 1.0c for the Q5 release. In addition, I had made some changes to fix INTx and Power Management related issues, which will be included in the release. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Wednesday, June 20, 2012 7:10 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Q4 release and contributions All- I've got a request for the community... thus far Intel has been making most of the contributions since we went open source and I'd like to encourage everyone to push your changes back to the base so we realize the benefits of being open source. I've got another patch that I'll be submitting (mentioned before) with some bug fixes plus I added support for DB strides. I'm hoping someone will sign up for the following 2 feature investigations/additions. One is changes for storport in Win8, many of the items won't be needed right away but I'd like someone to sign up to investigate and implement the things that make sense for the open source driver (setting a good example for optimizations in Win8). Secondly is support for 1.0c, I've listed the doc deltas and am looking for an owner to further investigate each item and implement the changes. Alex/Rick/Arpit... anyone who has not contributed? Can you look at picking these things up? Timeframe is to have them in and tested before the end of this quarter so we're ready for our Q5 release. Thanks Paul STORPORT FOR WIN8 http://msdn.microsoft.com/en-us/library/windows/hardware/hh451200%28v=vs.85%29.aspx 1.0c SUPPORT [ ]Invalid Doorbell Write handling - page 41 [ ]Need to make sure our IOCTL pipe checks vendor unique command format - page 44 [ ]Need to support "Firmware Application Requires Conventional Reset" response to Firmware Activate - page 49, page 62 [ ]Only abort asynchronous event requests when the controller is reset (not on queue deletion) - page 56 [ ]Firmware image download field NUMD is now 0s based value - page 63 [ ]Get Log Page field NUMD is 0's based - page 65 [ ]Get Log Page field Status Field, bit 00 is Phase Tag - page 66 [ ]Identify Controller - new fields "Admin Vendor Specific Command Configuration" and "NVM Vendor Specific Command Configuration" - page 71 & 73 [ ]Security Receive - length field changed from 16 to 32 bits, expanded into LSBs - page 87 [ ]Security Send - length field changed from 16 to 32 bits, expanded into LSBs - page 89 [ ]Definition added for deallocated metadata return, all 1's - page 97 ____________________________________ 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 kens at openfabrics.org Sat Jun 23 11:35:39 2012 From: kens at openfabrics.org (Ken Strandberg) Date: Sat, 23 Jun 2012 11:35:39 -0700 Subject: [nvmewin] sofa.openfabrics.org Message-ID: Our old server, sofa.openfabrics.org, will be decommissioned in the next couple weeks. Please make sure all your files are moved to beany.openfabrics.org. Thanks. -- *Ken Strandberg* *Webmanager/SysAdmin* *OpenFabrics Alliance* kens at openfabrics.org www.openfabrics.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Sat Jun 23 12:40:51 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Sat, 23 Jun 2012 19:40:51 +0000 Subject: [nvmewin] a few defects... Message-ID: <82C9F782B054C94B9FC04A331649C77A02587975@FMSMSX106.amr.corp.intel.com> So I finished creating my patch, just need to test, so will send out it on Mon. It's a few hundred edits so I'm not going to list them one by one but here are the fixes/changes and it will be obvious when you diff them which edit goes with which item: - report luns still had an issue in the format of the response data, the actual LUN # was 1 byte off so if you really had multiple LUNS, storport wouldn't scan them - the NVME_CC_IOSQES and CQ definitions in nvmereg.h were wrong (should be 6 and 4 respectively) - double buffering code needed a few tweaks if anyone tried to enable that they would have found out (tweaks based on changes made since it was originally coded). In addition, I ran into some HW that needed the PRP2 list pointer 4K aligned (part of debug) as well as the host data buffers so I added code to allocate one page of aligned memory per IO for PRP lists. For various reasons (mainly mem consumption) I extended the DBL_BUFF define to include some other things that dumb down the driver for HW bring up and debug. So, I renamed the compile switch to DUMB_DRIVER and when you define it you create a very simple driver via eliminating the following (in addition to making everything 4K aligned) -- learning mode -- NUMA and INT steering (limits to just one QP now) - small bug in get/set features portion of init state machine where we don't do both set & get on all LUNs - we didn't support DB strides in the driver - they are defined in the spec and yes there's a paragraph about these being useful in SW simulations, etc, but they can also be useful for other reasons as well. The changes are scattered through a few files and the formulas that you see for calc'ing DB locations come right out of the spec. In the nvmereg header there were changes to how we dinfed the structs that overlay the BAR; since strides are between DBs and not QPs I had to eliminate a few QP specific structs and make some generic ones to allow a variable sized array of generic (head or tail) DB register structs to overlay however big the BAR is when mapped into mem in FindAdapter. Before we had an array of like 1000 QP structs which doesn't work for strides and didn't make sense given everyone's HW will have different sized BARs (I'm assuming) - we weren't reading the upper 32 of CAP and failed to honor MQES (max Q entries supported by HW). I moved reading of CAP to findAdapter to we could do this and also keep a copy in the devExt now as well - we weren't honoring what the ctrl told us about the vol write cache get/set commands in the ID data. We sent them (via SCSI xlation) even if the card says it can't support the commands (which is odd, I'd think we'd want the card to accept all commands and just tell us when not supported but that's not how the spec reads). So, there are SNTI changes to not send these commands on mode sense/select for the cache page and instead hard code a page back that says 'no write cache' - a few misc chatham updates, won't go into those. Next patch I'll remove the CHATHAM define and all its associated code, only need it for a few more weeks Thx Paul From: Luse, Paul E Sent: Monday, June 18, 2012 12:05 PM To: nvmewin at lists.openfabrics.org Subject: a few defects... Just an FYI in case anyone is running into these. We have fixes for them and will work on getting a patch in either this week or next (want to wait til Ray is able to get the last one applied following the server change). - report luns still had an issue in the format of the response data, the actual LUN # was 1 byte off so if you really had multiple LUNS, storport wouldn't scan them - the NVME_CC_IOSQES and CQ definitions in nvmereg.h were wrong (should be 6 and 4 respectively) - double buffering code needed a few tweaks if anyone tried to enable that they would have found out (tweaks based on changes made since it was originally coded) - small bug in get/set features portion of init state machine where we don't do both set & get on all LUNs ____________________________________ 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 Mon Jun 25 10:19:39 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Mon, 25 Jun 2012 17:19:39 +0000 Subject: [nvmewin] ***UNCHECKED*** RE: a few defects... updated code attached Message-ID: <82C9F782B054C94B9FC04A331649C77A02593883@FMSMSX106.amr.corp.intel.com> Was able to start testing over the weekend. No new issues found so please start you review (complete set attached, compare against last applied tag, 'prp_list_count_bug_fix'). Password is intel123 I'll ping key folks for feedback if I don't hear anything in the next week or two. Again, the fixes are not super complicated so I won't schedule a review meeting unless someone requests it -- if anyone wants to, that's OK, just ask. Thanks Paul From: Luse, Paul E Sent: Saturday, June 23, 2012 12:41 PM To: nvmewin at lists.openfabrics.org Subject: RE: a few defects... So I finished creating my patch, just need to test, so will send out it on Mon. It's a few hundred edits so I'm not going to list them one by one but here are the fixes/changes and it will be obvious when you diff them which edit goes with which item: - report luns still had an issue in the format of the response data, the actual LUN # was 1 byte off so if you really had multiple LUNS, storport wouldn't scan them - the NVME_CC_IOSQES and CQ definitions in nvmereg.h were wrong (should be 6 and 4 respectively) - double buffering code needed a few tweaks if anyone tried to enable that they would have found out (tweaks based on changes made since it was originally coded). In addition, I ran into some HW that needed the PRP2 list pointer 4K aligned (part of debug) as well as the host data buffers so I added code to allocate one page of aligned memory per IO for PRP lists. For various reasons (mainly mem consumption) I extended the DBL_BUFF define to include some other things that dumb down the driver for HW bring up and debug. So, I renamed the compile switch to DUMB_DRIVER and when you define it you create a very simple driver via eliminating the following (in addition to making everything 4K aligned) -- learning mode -- NUMA and INT steering (limits to just one QP now) - small bug in get/set features portion of init state machine where we don't do both set & get on all LUNs - we didn't support DB strides in the driver - they are defined in the spec and yes there's a paragraph about these being useful in SW simulations, etc, but they can also be useful for other reasons as well. The changes are scattered through a few files and the formulas that you see for calc'ing DB locations come right out of the spec. In the nvmereg header there were changes to how we dinfed the structs that overlay the BAR; since strides are between DBs and not QPs I had to eliminate a few QP specific structs and make some generic ones to allow a variable sized array of generic (head or tail) DB register structs to overlay however big the BAR is when mapped into mem in FindAdapter. Before we had an array of like 1000 QP structs which doesn't work for strides and didn't make sense given everyone's HW will have different sized BARs (I'm assuming) - we weren't reading the upper 32 of CAP and failed to honor MQES (max Q entries supported by HW). I moved reading of CAP to findAdapter to we could do this and also keep a copy in the devExt now as well - we weren't honoring what the ctrl told us about the vol write cache get/set commands in the ID data. We sent them (via SCSI xlation) even if the card says it can't support the commands (which is odd, I'd think we'd want the card to accept all commands and just tell us when not supported but that's not how the spec reads). So, there are SNTI changes to not send these commands on mode sense/select for the cache page and instead hard code a page back that says 'no write cache' - a few misc chatham updates, won't go into those. Next patch I'll remove the CHATHAM define and all its associated code, only need it for a few more weeks Thx Paul From: Luse, Paul E Sent: Monday, June 18, 2012 12:05 PM To: nvmewin at lists.openfabrics.org Subject: a few defects... Just an FYI in case anyone is running into these. We have fixes for them and will work on getting a patch in either this week or next (want to wait til Ray is able to get the last one applied following the server change). - report luns still had an issue in the format of the response data, the actual LUN # was 1 byte off so if you really had multiple LUNS, storport wouldn't scan them - the NVME_CC_IOSQES and CQ definitions in nvmereg.h were wrong (should be 6 and 4 respectively) - double buffering code needed a few tweaks if anyone tried to enable that they would have found out (tweaks based on changes made since it was originally coded) - small bug in get/set features portion of init state machine where we don't do both set & get on all LUNs ____________________________________ 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: source.zip Type: application/x-zip-compressed Size: 160673 bytes Desc: source.zip URL: From james.p.freyensee at intel.com Mon Jun 25 16:30:22 2012 From: james.p.freyensee at intel.com (Freyensee, James P) Date: Mon, 25 Jun 2012 23:30:22 +0000 Subject: [nvmewin] Driver provided alignment for RMW? Message-ID: <2D98093777D3FD46A36253F35FE9D69346B85E82@ORSMSX101.amr.corp.intel.com> Hello, Could I ask a 'what if'/brainstorming question? Does the nvme driver provide some type of data alignment on Read-Modify-Writes? Could the driver enforce 4K alignments? Where would I look/modify in the code? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Mon Jun 25 16:35:03 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Mon, 25 Jun 2012 23:35:03 +0000 Subject: [nvmewin] Driver provided alignment for RMW? In-Reply-To: <2D98093777D3FD46A36253F35FE9D69346B85E82@ORSMSX101.amr.corp.intel.com> References: <2D98093777D3FD46A36253F35FE9D69346B85E82@ORSMSX101.amr.corp.intel.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A0259DBF2@FMSMSX106.amr.corp.intel.com> If you look at the defines for DBL_BUFFER (or in the patch I just sent DUMB_DRIVER) you'll see debug code for 4K alignments. I say debug because it does so via double buffering (copying data in/out of our own 4K aligned buffers) because storport will only allow you to specify up to double dword alignment in the config structure you return from findAdapter (element name is AlignmentMask). I added the 4K debug code because the initial implementation of the software emulator that we used only supported 4K aligned transfers and kept it in there to help with HW bring-ups where this seemed like a common restriction. For production, you'd want to ask Mssft about changing what alignments a storport miniport can request. From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Freyensee, James P Sent: Monday, June 25, 2012 4:30 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Driver provided alignment for RMW? Hello, Could I ask a 'what if'/brainstorming question? Does the nvme driver provide some type of data alignment on Read-Modify-Writes? Could the driver enforce 4K alignments? Where would I look/modify in the code? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.p.freyensee at intel.com Mon Jun 25 16:38:02 2012 From: james.p.freyensee at intel.com (Freyensee, James P) Date: Mon, 25 Jun 2012 23:38:02 +0000 Subject: [nvmewin] Driver provided alignment for RMW? In-Reply-To: <82C9F782B054C94B9FC04A331649C77A0259DBF2@FMSMSX106.amr.corp.intel.com> References: <2D98093777D3FD46A36253F35FE9D69346B85E82@ORSMSX101.amr.corp.intel.com> <82C9F782B054C94B9FC04A331649C77A0259DBF2@FMSMSX106.amr.corp.intel.com> Message-ID: <2D98093777D3FD46A36253F35FE9D69346B85E9E@ORSMSX101.amr.corp.intel.com> Thanks for this. Yes, we'd be interested in 4K debug code for HW bring-ups as well. If there is a bug in the HW 1st gen, then we can still have SW provide the boundry. From: Luse, Paul E Sent: Monday, June 25, 2012 4:35 PM To: Freyensee, James P; nvmewin at lists.openfabrics.org Subject: RE: Driver provided alignment for RMW? If you look at the defines for DBL_BUFFER (or in the patch I just sent DUMB_DRIVER) you'll see debug code for 4K alignments. I say debug because it does so via double buffering (copying data in/out of our own 4K aligned buffers) because storport will only allow you to specify up to double dword alignment in the config structure you return from findAdapter (element name is AlignmentMask). I added the 4K debug code because the initial implementation of the software emulator that we used only supported 4K aligned transfers and kept it in there to help with HW bring-ups where this seemed like a common restriction. For production, you'd want to ask Mssft about changing what alignments a storport miniport can request. From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Freyensee, James P Sent: Monday, June 25, 2012 4:30 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Driver provided alignment for RMW? Hello, Could I ask a 'what if'/brainstorming question? Does the nvme driver provide some type of data alignment on Read-Modify-Writes? Could the driver enforce 4K alignments? Where would I look/modify in the code? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Mon Jun 25 16:38:56 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Mon, 25 Jun 2012 23:38:56 +0000 Subject: [nvmewin] Driver provided alignment for RMW? In-Reply-To: <2D98093777D3FD46A36253F35FE9D69346B85E9E@ORSMSX101.amr.corp.intel.com> References: <2D98093777D3FD46A36253F35FE9D69346B85E82@ORSMSX101.amr.corp.intel.com> <82C9F782B054C94B9FC04A331649C77A0259DBF2@FMSMSX106.amr.corp.intel.com> <2D98093777D3FD46A36253F35FE9D69346B85E9E@ORSMSX101.amr.corp.intel.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A0259DD00@FMSMSX106.amr.corp.intel.com> Cool, read the notes I sent out on DUMB_DRIVER and you'll see the other things that go along with it, all helpful for bringing up HW for the first time From: Freyensee, James P Sent: Monday, June 25, 2012 4:38 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: Driver provided alignment for RMW? Thanks for this. Yes, we'd be interested in 4K debug code for HW bring-ups as well. If there is a bug in the HW 1st gen, then we can still have SW provide the boundry. From: Luse, Paul E Sent: Monday, June 25, 2012 4:35 PM To: Freyensee, James P; nvmewin at lists.openfabrics.org Subject: RE: Driver provided alignment for RMW? If you look at the defines for DBL_BUFFER (or in the patch I just sent DUMB_DRIVER) you'll see debug code for 4K alignments. I say debug because it does so via double buffering (copying data in/out of our own 4K aligned buffers) because storport will only allow you to specify up to double dword alignment in the config structure you return from findAdapter (element name is AlignmentMask). I added the 4K debug code because the initial implementation of the software emulator that we used only supported 4K aligned transfers and kept it in there to help with HW bring-ups where this seemed like a common restriction. For production, you'd want to ask Mssft about changing what alignments a storport miniport can request. From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Freyensee, James P Sent: Monday, June 25, 2012 4:30 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Driver provided alignment for RMW? Hello, Could I ask a 'what if'/brainstorming question? Does the nvme driver provide some type of data alignment on Read-Modify-Writes? Could the driver enforce 4K alignments? Where would I look/modify in the code? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: