From raymond.c.robles at intel.com Thu Jan 14 15:54:48 2016 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Thu, 14 Jan 2016 23:54:48 +0000 Subject: [nvmewin] Happy New Year... and status update Message-ID: <49158E750348AA499168FD41D8898360725821BA@fmsmsx117.amr.corp.intel.com> Hello and Happy New Year, I hope everyone had a great holiday season and is off to a great start to the new year! As communicated last month, the patch from HGST for the SCSI multi-initiator changes has been approved and pushed. The holidays slowed down much of the progress on the OFA driver and there were several patches that did not get pushed prior to the end of the year. The list of patches remained to be pushed are as follows... * Namespace Management (Intel) * Perf Opts (Samsung) * Win 8.1 Timers (Samsung) * EOL Read Only (Samsung) * Concurrent channels (Google) The namespace management patch will be sent out for review tomorrow (look for the patch email from Carolyn)... stay tuned!!! However, once this patch is resolved, we as a community will have to make a decision on an official release strategy. The patch process and cadence was significantly slower in 2015 which leaves us with a few options. 1. Release what is in the trunk today (or after the namespace management patch)... and call that the 2015 release (albeit later than expected) 2. In lieu of an official 2015 release, we push the remaining patches listed above... and then release in ~Q2 of 2015. Basically skip a 2015 release and go right into the mid-2016 release. 3. Remove the concept of "official releases" from the OFA Windows NVMe driver and just allow people, companies, and users to pull from the OFA trunk as necessary. For #3 above, my thoughts are that because the OFA driver is not a production driver... but a reference and enabling driver, it should/could be managed as just that... a reference baseline driver that any potential user can go and grab the source, or contribute a patch. Nothing more... nothing less. For the release decision, I'll be happy to call a meeting... but we can also handle it via email as well... just let me know. Feedback from all is welcome... but I would request mandatory feedback form the 4 reviewing companies: Samsung, HGST, PMC-Sierra, and Intel. How would you like to proceed? Thanks, Ray [cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles Non-Volatile Memory Solutions Group Intel Corporation Office: 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 thomas.freeman at hgst.com Fri Jan 15 08:04:00 2016 From: thomas.freeman at hgst.com (Thomas Freeman) Date: Fri, 15 Jan 2016 16:04:00 +0000 Subject: [nvmewin] Happy New Year... and status update In-Reply-To: <49158E750348AA499168FD41D8898360725821BA@fmsmsx117.amr.corp.intel.com> References: <49158E750348AA499168FD41D8898360725821BA@fmsmsx117.amr.corp.intel.com> Message-ID: Ray, Is this purely a question of how the changes are packaged? Or do any of these options imply what type of fixes/changes will be delivered in the future? i.e. Does choosing option 3 imply that the driver is going into purely maintenance mode? Or with that option, would there still be a coordinated effort to release new function along with fixes? Thanks, Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, January 14, 2016 5:55 PM To: 'nvmewin at lists.openfabrics.org' Subject: [nvmewin] Happy New Year... and status update Hello and Happy New Year, I hope everyone had a great holiday season and is off to a great start to the new year! As communicated last month, the patch from HGST for the SCSI multi-initiator changes has been approved and pushed. The holidays slowed down much of the progress on the OFA driver and there were several patches that did not get pushed prior to the end of the year. The list of patches remained to be pushed are as follows... * Namespace Management (Intel) * Perf Opts (Samsung) * Win 8.1 Timers (Samsung) * EOL Read Only (Samsung) * Concurrent channels (Google) The namespace management patch will be sent out for review tomorrow (look for the patch email from Carolyn)... stay tuned!!! However, once this patch is resolved, we as a community will have to make a decision on an official release strategy. The patch process and cadence was significantly slower in 2015 which leaves us with a few options. 1. Release what is in the trunk today (or after the namespace management patch)... and call that the 2015 release (albeit later than expected) 2. In lieu of an official 2015 release, we push the remaining patches listed above... and then release in ~Q2 of 2015. Basically skip a 2015 release and go right into the mid-2016 release. 3. Remove the concept of "official releases" from the OFA Windows NVMe driver and just allow people, companies, and users to pull from the OFA trunk as necessary. For #3 above, my thoughts are that because the OFA driver is not a production driver... but a reference and enabling driver, it should/could be managed as just that... a reference baseline driver that any potential user can go and grab the source, or contribute a patch. Nothing more... nothing less. For the release decision, I'll be happy to call a meeting... but we can also handle it via email as well... just let me know. Feedback from all is welcome... but I would request mandatory feedback form the 4 reviewing companies: Samsung, HGST, PMC-Sierra, and Intel. How would you like to proceed? Thanks, Ray [cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles Non-Volatile Memory Solutions Group Intel Corporation Office: 480-554-2600 Mobile: 480-399-0645 HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 4274 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 1756 bytes Desc: image003.png URL: From raymond.c.robles at intel.com Fri Jan 15 13:54:03 2016 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Fri, 15 Jan 2016 21:54:03 +0000 Subject: [nvmewin] Happy New Year... and status update In-Reply-To: References: <49158E750348AA499168FD41D8898360725821BA@fmsmsx117.amr.corp.intel.com> Message-ID: <49158E750348AA499168FD41D8898360725834C1@fmsmsx117.amr.corp.intel.com> Hi Tom, Great questions... here are my thoughts. But I encourage others to chime in as well. Is this purely a question of how the changes are packaged? [RCR] Exactly! I am merely making a suggestion that will ease the burden of having mandatory releases... as well as having to adhere to a schedule that really has no meaning to any particular product since the OFA driver is a reference driver. Much like the Linux community, any vendor can take our baseline and package it up as needed, but for the community itself, it just manages bug fix and feature patches as they come in. Or do any of these options imply what type of fixes/changes will be delivered in the future? i.e. Does choosing option 3 imply that the driver is going into purely maintenance mode? [RCR] Not at all. Option 3 is simply us doing what we've done all along... with the exception of not doing any "official releases". All bug fix and feature patches would still be graciously accepted... and welcome :). Or with that option, would there still be a coordinated effort to release new function along with fixes? [RCR] Exactly... see above responses. Does this answer your questions Tom? Thanks, Ray From: Thomas Freeman [mailto:thomas.freeman at hgst.com] Sent: Friday, January 15, 2016 9:04 AM To: Robles, Raymond C; 'nvmewin at lists.openfabrics.org' Subject: RE: Happy New Year... and status update Ray, Is this purely a question of how the changes are packaged? Or do any of these options imply what type of fixes/changes will be delivered in the future? i.e. Does choosing option 3 imply that the driver is going into purely maintenance mode? Or with that option, would there still be a coordinated effort to release new function along with fixes? Thanks, Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, January 14, 2016 5:55 PM To: 'nvmewin at lists.openfabrics.org' > Subject: [nvmewin] Happy New Year... and status update Hello and Happy New Year, I hope everyone had a great holiday season and is off to a great start to the new year! As communicated last month, the patch from HGST for the SCSI multi-initiator changes has been approved and pushed. The holidays slowed down much of the progress on the OFA driver and there were several patches that did not get pushed prior to the end of the year. The list of patches remained to be pushed are as follows... * Namespace Management (Intel) * Perf Opts (Samsung) * Win 8.1 Timers (Samsung) * EOL Read Only (Samsung) * Concurrent channels (Google) The namespace management patch will be sent out for review tomorrow (look for the patch email from Carolyn)... stay tuned!!! However, once this patch is resolved, we as a community will have to make a decision on an official release strategy. The patch process and cadence was significantly slower in 2015 which leaves us with a few options. 1. Release what is in the trunk today (or after the namespace management patch)... and call that the 2015 release (albeit later than expected) 2. In lieu of an official 2015 release, we push the remaining patches listed above... and then release in ~Q2 of 2015. Basically skip a 2015 release and go right into the mid-2016 release. 3. Remove the concept of "official releases" from the OFA Windows NVMe driver and just allow people, companies, and users to pull from the OFA trunk as necessary. For #3 above, my thoughts are that because the OFA driver is not a production driver... but a reference and enabling driver, it should/could be managed as just that... a reference baseline driver that any potential user can go and grab the source, or contribute a patch. Nothing more... nothing less. For the release decision, I'll be happy to call a meeting... but we can also handle it via email as well... just let me know. Feedback from all is welcome... but I would request mandatory feedback form the 4 reviewing companies: Samsung, HGST, PMC-Sierra, and Intel. How would you like to proceed? Thanks, Ray [cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles Non-Volatile Memory Solutions Group Intel Corporation Office: 480-554-2600 Mobile: 480-399-0645 HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4274 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 1756 bytes Desc: image002.png URL: From carolyn.d.foster at intel.com Fri Jan 15 15:57:26 2016 From: carolyn.d.foster at intel.com (Foster, Carolyn D) Date: Fri, 15 Jan 2016 23:57:26 +0000 Subject: [nvmewin] Patch with changes for Namespace Management Message-ID: Hi all, This patch includes changes to support Namespace Management updates from the NVMe specification 1.2. This patch implements some fixes for handling non-continuous namespaces, adds handling for attached and detached namespaces, and implements new IOCTLs to create, delete, attach and detach namespaces. I have made a detailed overview of the changes in the text file in the attached zip file, the contents are also copied here below. Password is intelnvme Please let me know if you have any questions. Carolyn Foster This patch includes changes to support Namespace management, including create, delete, attach and detach namespace operations. The new functionality in this patch was tested using proprietary tools. We tested on Server 2008 R2, Server 2012 R2 and Windows 8.1 ****************** Design Assumptions ****************** 1. The numbering of namespaces need not be consecutive. 2. The namespace ID can be any number between 1 and 2^32. 3. A namespace is considered "active" only when it is created and attached to this controller. 4. A detached namespace, or one that is just created but not yet attached is considered "inactive". 5. A non-existent, or deleted namespace is considered "invalid". 6. An active namespace will result in one (and only one) "Online" LUN. 7. Assuming single-host, and single-controller NVMe system. ********************* Architecture Overview ********************* There are four new IOCTLs for namespace management, Create, Delete, Attach and Detach. An attached namespace will result in a visible LUN to the Windows OS. The LUN extension table has been updated to have a Namespace status: typedef enum _NS_STATUS { INVALID = 0, //Namespace ID does not exist (not known to controller). INACTIVE, //Namespace is created, but not attached to controller. ATTACHED //Namespace is created and attached to controller. } NS_STATUS; In order to properly build the LUN extension table during initialization, we made changes to identify all namespaces, and to determine each namespace's status. These changes include new states in the Init State Machine NVMeRnningWaitOnListAttachedNs and NVMeRunningWaitOnListExistingNs. The updated state machine steps are as follows: 1. Send an Identify Namespace command with CNS set to 02h. This should return a list of all active (created and attached) namespaces. 2. Go through the list and update LUN extension entries accordingly, one entry for each namespace. Set all LUN status to online. 3. Send an Identify Namespace command with CNS set to 10h. This should return a list of all existing namespaces in the system, active and inactive. 4. Go through the list. 5. If a corresponding LUN entry exists, skip this step, as this must have been an active namespace that was covered in previous steps. LUN extension entries are populated as follows: When a namespace is created: - namespaceId is set. - nsStatus is set to "INACTIVE" - slotStatus is set to "FREE" - identifyData is partially set When a namespace is attached: - drive is pulled for namespace identify - identifyData is set accordingly - nsStatus is set to "ATTACHED" - slotStatus is set to "ONLINE" - ReadOnly is set to FALSE When a namespace is detached: - nsStatus is set to "INACTIVE" - slotStatus is set to "FREE" - ReadOnly is set to TRUE When a namespace is deleted: - The entire LUN extension entry is set to 0. There are also new reasons for the LUN to be offline: typedef enum _LUN_OFFLINE_REASON { NOT_OFFLINE, FORMAT_IN_PROGRESS, DETACH_IN_PROGRESS, DELETE_IN_PROGRESS // Add more as needed } LUN_OFFLINE_REASON; When delete or detach requests are made, the driver will call StorportDeviceBusy to pause incoming requests, and the LUN is marked as offline with the appropriate reason. When a user tries to delete an attached namespace, the driver will first send a detach command, and then the delete command. ***************** Known Limitations ***************** 1. If no namepsaces are present, the driver will fail to load. 2. If an error happens on any one namespace during initialization the driver will fail to load. The handling for these two scenarios could be strengthened and improved, which we did not get to in this patch. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IntelNamespaceManagementV1.zip Type: application/x-zip-compressed Size: 222253 bytes Desc: IntelNamespaceManagementV1.zip URL: From judy.brock at ssi.samsung.com Tue Jan 19 06:32:45 2016 From: judy.brock at ssi.samsung.com (Judy Brock-SSI) Date: Tue, 19 Jan 2016 14:32:45 +0000 Subject: [nvmewin] Happy New Year... and status update In-Reply-To: <49158E750348AA499168FD41D8898360725821BA@fmsmsx117.amr.corp.intel.com> References: <49158E750348AA499168FD41D8898360725821BA@fmsmsx117.amr.corp.intel.com> Message-ID: <36E8D38D6B771A4BBDB1C0D800158A51865B7376@SSIEXCH-MB3.ssi.samsung.com> Hi Ray, We are still discussing internally. We will let you know which option we vote for soon! Regards, Judy From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, January 14, 2016 3:55 PM To: 'nvmewin at lists.openfabrics.org' Subject: [nvmewin] Happy New Year... and status update Hello and Happy New Year, I hope everyone had a great holiday season and is off to a great start to the new year! As communicated last month, the patch from HGST for the SCSI multi-initiator changes has been approved and pushed. The holidays slowed down much of the progress on the OFA driver and there were several patches that did not get pushed prior to the end of the year. The list of patches remained to be pushed are as follows... * Namespace Management (Intel) * Perf Opts (Samsung) * Win 8.1 Timers (Samsung) * EOL Read Only (Samsung) * Concurrent channels (Google) The namespace management patch will be sent out for review tomorrow (look for the patch email from Carolyn)... stay tuned!!! However, once this patch is resolved, we as a community will have to make a decision on an official release strategy. The patch process and cadence was significantly slower in 2015 which leaves us with a few options. 1. Release what is in the trunk today (or after the namespace management patch)... and call that the 2015 release (albeit later than expected) 2. In lieu of an official 2015 release, we push the remaining patches listed above... and then release in ~Q2 of 2015. Basically skip a 2015 release and go right into the mid-2016 release. 3. Remove the concept of "official releases" from the OFA Windows NVMe driver and just allow people, companies, and users to pull from the OFA trunk as necessary. For #3 above, my thoughts are that because the OFA driver is not a production driver... but a reference and enabling driver, it should/could be managed as just that... a reference baseline driver that any potential user can go and grab the source, or contribute a patch. Nothing more... nothing less. For the release decision, I'll be happy to call a meeting... but we can also handle it via email as well... just let me know. Feedback from all is welcome... but I would request mandatory feedback form the 4 reviewing companies: Samsung, HGST, PMC-Sierra, and Intel. How would you like to proceed? Thanks, Ray [cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles Non-Volatile Memory Solutions Group Intel Corporation Office: 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 thomas.freeman at hgst.com Tue Jan 19 06:41:36 2016 From: thomas.freeman at hgst.com (Thomas Freeman) Date: Tue, 19 Jan 2016 14:41:36 +0000 Subject: [nvmewin] Happy New Year... and status update In-Reply-To: <49158E750348AA499168FD41D8898360725834C1@fmsmsx117.amr.corp.intel.com> References: <49158E750348AA499168FD41D8898360725821BA@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D8898360725834C1@fmsmsx117.amr.corp.intel.com> Message-ID: Thanks for the response Ray. I'm fine with option 3. Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Friday, January 15, 2016 3:54 PM To: Thomas Freeman Cc: 'nvmewin at lists.openfabrics.org' Subject: RE: Happy New Year... and status update Hi Tom, Great questions... here are my thoughts. But I encourage others to chime in as well. Is this purely a question of how the changes are packaged? [RCR] Exactly! I am merely making a suggestion that will ease the burden of having mandatory releases... as well as having to adhere to a schedule that really has no meaning to any particular product since the OFA driver is a reference driver. Much like the Linux community, any vendor can take our baseline and package it up as needed, but for the community itself, it just manages bug fix and feature patches as they come in. Or do any of these options imply what type of fixes/changes will be delivered in the future? i.e. Does choosing option 3 imply that the driver is going into purely maintenance mode? [RCR] Not at all. Option 3 is simply us doing what we've done all along... with the exception of not doing any "official releases". All bug fix and feature patches would still be graciously accepted... and welcome :). Or with that option, would there still be a coordinated effort to release new function along with fixes? [RCR] Exactly... see above responses. Does this answer your questions Tom? Thanks, Ray From: Thomas Freeman [mailto:thomas.freeman at hgst.com] Sent: Friday, January 15, 2016 9:04 AM To: Robles, Raymond C; 'nvmewin at lists.openfabrics.org' Subject: RE: Happy New Year... and status update Ray, Is this purely a question of how the changes are packaged? Or do any of these options imply what type of fixes/changes will be delivered in the future? i.e. Does choosing option 3 imply that the driver is going into purely maintenance mode? Or with that option, would there still be a coordinated effort to release new function along with fixes? Thanks, Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, January 14, 2016 5:55 PM To: 'nvmewin at lists.openfabrics.org' > Subject: [nvmewin] Happy New Year... and status update Hello and Happy New Year, I hope everyone had a great holiday season and is off to a great start to the new year! As communicated last month, the patch from HGST for the SCSI multi-initiator changes has been approved and pushed. The holidays slowed down much of the progress on the OFA driver and there were several patches that did not get pushed prior to the end of the year. The list of patches remained to be pushed are as follows... * Namespace Management (Intel) * Perf Opts (Samsung) * Win 8.1 Timers (Samsung) * EOL Read Only (Samsung) * Concurrent channels (Google) The namespace management patch will be sent out for review tomorrow (look for the patch email from Carolyn)... stay tuned!!! However, once this patch is resolved, we as a community will have to make a decision on an official release strategy. The patch process and cadence was significantly slower in 2015 which leaves us with a few options. 1. Release what is in the trunk today (or after the namespace management patch)... and call that the 2015 release (albeit later than expected) 2. In lieu of an official 2015 release, we push the remaining patches listed above... and then release in ~Q2 of 2015. Basically skip a 2015 release and go right into the mid-2016 release. 3. Remove the concept of "official releases" from the OFA Windows NVMe driver and just allow people, companies, and users to pull from the OFA trunk as necessary. For #3 above, my thoughts are that because the OFA driver is not a production driver... but a reference and enabling driver, it should/could be managed as just that... a reference baseline driver that any potential user can go and grab the source, or contribute a patch. Nothing more... nothing less. For the release decision, I'll be happy to call a meeting... but we can also handle it via email as well... just let me know. Feedback from all is welcome... but I would request mandatory feedback form the 4 reviewing companies: Samsung, HGST, PMC-Sierra, and Intel. How would you like to proceed? Thanks, Ray [cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles Non-Volatile Memory Solutions Group Intel Corporation Office: 480-554-2600 Mobile: 480-399-0645 HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4274 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 1756 bytes Desc: image002.png URL: From judy.brock at ssi.samsung.com Tue Jan 19 15:38:13 2016 From: judy.brock at ssi.samsung.com (Judy Brock-SSI) Date: Tue, 19 Jan 2016 23:38:13 +0000 Subject: [nvmewin] Happy New Year... and status update References: <49158E750348AA499168FD41D8898360725821BA@fmsmsx117.amr.corp.intel.com> Message-ID: <36E8D38D6B771A4BBDB1C0D800158A51865B765A@SSIEXCH-MB3.ssi.samsung.com> Hi Ray, We strongly prefer Options #2. We think it is important to continue supporting OFA official releases for some time to come. We also don't think it makes sense to release what is in the trunk today as a 2015 release and then follow up almost immediately on its heels with a 2016 release containing all the patches below. Hence our vote for Option #2. Samsung is very comfortable in committing to delivering the 3 patches below in the Option #2 timeframe. In fact, we will be ready with our first patch(PerfOpts + 2 critical bug fixes - see below) after 5 days of pushing the Namespace management patch to main branch. In addition to PerfOpts support, we will be including two critical bug fixes in our first patch - both fixes for BSODs: 1. The first bug fix addresses the following: There is a basic race condition/synchronization issue in the driver which allows the Admin queue's linked list of cmd_entry structures (pSQI->FreeQList) to get corrupted. In the current code, this list can be manipulated by different processors concurrently. When that happens, a BSOD ("A LIST_ENTRY has been corrupted (i.e. double remove)") occurs. This hole is fixed. 2. The second bug fix addresses the following: If a new SRB that comes in while a Format NVM is in progress, the NVMeBuildIo looks at the SCSI CDB opcode and rejects reads/writes. The code that does this checking needs to make sure the request coming in is a SCSI-CDB based request before it tries to look at the CDB opcode - but it does not. The logic is in the wrong place in NVMeBuildIo. The current code results in an attempt to access a null pointer and BSODs. Thanks, Judy From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, January 14, 2016 3:55 PM To: 'nvmewin at lists.openfabrics.org' Subject: [nvmewin] Happy New Year... and status update Hello and Happy New Year, I hope everyone had a great holiday season and is off to a great start to the new year! As communicated last month, the patch from HGST for the SCSI multi-initiator changes has been approved and pushed. The holidays slowed down much of the progress on the OFA driver and there were several patches that did not get pushed prior to the end of the year. The list of patches remained to be pushed are as follows... * Namespace Management (Intel) * Perf Opts (Samsung) * Win 8.1 Timers (Samsung) * EOL Read Only (Samsung) * Concurrent channels (Google) The namespace management patch will be sent out for review tomorrow (look for the patch email from Carolyn)... stay tuned!!! However, once this patch is resolved, we as a community will have to make a decision on an official release strategy. The patch process and cadence was significantly slower in 2015 which leaves us with a few options. 1. Release what is in the trunk today (or after the namespace management patch)... and call that the 2015 release (albeit later than expected) 2. In lieu of an official 2015 release, we push the remaining patches listed above... and then release in ~Q2 of 2015. Basically skip a 2015 release and go right into the mid-2016 release. 3. Remove the concept of "official releases" from the OFA Windows NVMe driver and just allow people, companies, and users to pull from the OFA trunk as necessary. For #3 above, my thoughts are that because the OFA driver is not a production driver... but a reference and enabling driver, it should/could be managed as just that... a reference baseline driver that any potential user can go and grab the source, or contribute a patch. Nothing more... nothing less. For the release decision, I'll be happy to call a meeting... but we can also handle it via email as well... just let me know. Feedback from all is welcome... but I would request mandatory feedback form the 4 reviewing companies: Samsung, HGST, PMC-Sierra, and Intel. How would you like to proceed? Thanks, Ray [cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles Non-Volatile Memory Solutions Group Intel Corporation Office: 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 suman.p at samsung.com Wed Jan 20 08:10:29 2016 From: suman.p at samsung.com (SUMAN PRAKASH B) Date: Wed, 20 Jan 2016 16:10:29 +0000 (GMT) Subject: [nvmewin] Happy New Year... and status update Message-ID: <06.09.05149.571BF965@epcpsbgx2.samsung.com> An HTML attachment was scrubbed... URL: From raymond.c.robles at intel.com Wed Jan 20 12:45:29 2016 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Wed, 20 Jan 2016 20:45:29 +0000 Subject: [nvmewin] Happy New Year... and status update In-Reply-To: References: Message-ID: <49158E750348AA499168FD41D889836072588453@fmsmsx117.amr.corp.intel.com> Hi Suman/Judy, Thank you for your response. Right now, the current vote is... Samsung - Option #2 HGST - Option #3 PMC Sierra - TBD Alex/Kwok, what is your vote/preference on the release options below. Thanks, Ray From: SUMAN PRAKASH B [mailto:suman.p at samsung.com] Sent: Wednesday, January 20, 2016 9:10 AM To: Robles, Raymond C; nvmewin-request at lists.openfabrics.org; nvmewin at lists.openfabrics.org Cc: tru.nguyen at ssi.samsung.com; judy.brock at ssi.samsung.com; MANOJ THAPLIYAL; anshul at samsung.com Subject: Re: Happy New Year... and status update Hello Ray, Samsung votes for Option #2. We push the remaining patches listed and then release in ~Q2 of 2015. And as planned, Samsung will submit the following patches, along with some critical bug fixes. a) Perf Opts (Samsung) b) Win 8.1 Timers (Samsung) c) EOL Read Only (Samsung) And we will be ready with our first patch "Perf Opts" after 5 days of pushing the Namespace management patch to main branch. Please let us know your opinion. Regards, Suman ---------------------------------------------------------------------- Message: 1 Date: Tue, 19 Jan 2016 14:32:45 +0000 From: Judy Brock-SSI > To: "Robles, Raymond C" >, "'nvmewin at lists.openfabrics.org'" > Subject: Re: [nvmewin] Happy New Year... and status update Message-ID: <36E8D38D6B771A4BBDB1C0D800158A51865B7376 at SSIEXCH-MB3.ssi.samsung.com> Content-Type: text/plain; charset="us-ascii" Hi Ray, We are still discussing internally. We will let you know which option we vote for soon! Regards, Judy From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, January 14, 2016 3:55 PM To: 'nvmewin at lists.openfabrics.org' Subject: [nvmewin] Happy New Year... and status update Hello and Happy New Year, I hope everyone had a great holiday season and is off to a great start to the new year! As communicated last month, the patch from HGST for the SCSI multi-initiator changes has been approved and pushed. The holidays slowed down much of the progress on the OFA driver and there were several patches that did not get pushed prior to the end of the year. The list of patches remained to be pushed are as follows... * Namespace Management (Intel) * Perf Opts (Samsung) * Win 8.1 Timers (Samsung) * EOL Read Only (Samsung) * Concurrent channels (Google) The namespace management patch will be sent out for review tomorrow (look for the patch email from Carolyn)... stay tuned!!! However, once this patch is resolved, we as a community will have to make a decision on an official release strategy. The patch process and cadence was significantly slower in 2015 which leaves us with a few options. 1. Release what is in the trunk today (or after the namespace management patch)... and call that the 2015 release (albeit later than expected) 2. In lieu of an official 2015 release, we push the remaining patches listed above... and then release in ~Q2 of 2015. Basically skip a 2015 release and go right into the mid-2016 release. 3. Remove the concept of "official releases" from the OFA Windows NVMe driver and just allow people, companies, and users to pull from the OFA trunk as necessary. For #3 above, my thoughts are that because the OFA driver is not a production driver... but a reference and enabling driver, it should/could be managed as just that... a reference baseline driver that any potential user can go and grab the source, or contribute a patch. Nothing more... nothing less. For the release decision, I'll be happy to call a meeting... but we can also handle it via email as well... just let me know. Feedback from all is welcome... but I would request mandatory feedback form the 4 reviewing companies: Samsung, HGST, PMC-Sierra, and Intel. How would you like to proceed? Thanks, Ray [cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles Non-Volatile Memory Solutions Group Intel Corporation Office: 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: ------------------------------ Message: 2 Date: Tue, 19 Jan 2016 14:41:36 +0000 From: Thomas Freeman > To: "Robles, Raymond C" > Cc: "'nvmewin at lists.openfabrics.org'" > Subject: Re: [nvmewin] Happy New Year... and status update Message-ID: > Content-Type: text/plain; charset="us-ascii" Thanks for the response Ray. I'm fine with option 3. Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com> 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com> From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Friday, January 15, 2016 3:54 PM To: Thomas Freeman > Cc: 'nvmewin at lists.openfabrics.org' > Subject: RE: Happy New Year... and status update Hi Tom, Great questions... here are my thoughts. But I encourage others to chime in as well. Is this purely a question of how the changes are packaged? [RCR] Exactly! I am merely making a suggestion that will ease the burden of having mandatory releases... as well as having to adhere to a schedule that really has no meaning to any particular product since the OFA driver is a reference driver. Much like the Linux community, any vendor can take our baseline and package it up as needed, but for the community itself, it just manages bug fix and feature patches as they come in. Or do any of these options imply what type of fixes/changes will be delivered in the future? i.e. Does choosing option 3 imply that the driver is going into purely maintenance mode? [RCR] Not at all. Option 3 is simply us doing what we've done all along... with the exception of not doing any "official releases". All bug fix and feature patches would still be graciously accepted... and welcome :). Or with that option, would there still be a coordinated effort to release new function along with fixes? [RCR] Exactly... see above responses. Does this answer your questions Tom? Thanks, Ray From: Thomas Freeman [mailto:thomas.freeman at hgst.com] Sent: Friday, January 15, 2016 9:04 AM To: Robles, Raymond C; 'nvmewin at lists.openfabrics.org' Subject: RE: Happy New Year... and status update Ray, Is this purely a question of how the changes are packaged? Or do any of these options imply what type of fixes/changes will be delivered in the future? i.e. Does choosing option 3 imply that the driver is going into purely maintenance mode? Or with that option, would there still be a coordinated effort to release new function along with fixes? Thanks, Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com> 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com> From: nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, January 14, 2016 5:55 PM To: 'nvmewin at lists.openfabrics.org' >> Subject: [nvmewin] Happy New Year... and status update Hello and Happy New Year, I hope everyone had a great holiday season and is off to a great start to the new year! As communicated last month, the patch from HGST for the SCSI multi-initiator changes has been approved and pushed. The holidays slowed down much of the progress on the OFA driver and there were several patches that did not get pushed prior to the end of the year. The list of patches remained to be pushed are as follows... * Namespace Management (Intel) * Perf Opts (Samsung) * Win 8.1 Timers (Samsung) * EOL Read Only (Samsung) * Concurrent channels (Google) The namespace management patch will be sent out for review tomorrow (look for the patch email from Carolyn)... stay tuned!!! However, once this patch is resolved, we as a community will have to make a decision on an official release strategy. The patch process and cadence was significantly slower in 2015 which leaves us with a few options. 1. Release what is in the trunk today (or after the namespace management patch)... and call that the 2015 release (albeit later than expected) 2. In lieu of an official 2015 release, we push the remaining patches listed above... and then release in ~Q2 of 2015. Basically skip a 2015 release and go right into the mid-2016 release. 3. Remove the concept of "official releases" from the OFA Windows NVMe driver and just allow people, companies, and users to pull from the OFA trunk as necessary. For #3 above, my thoughts are that because the OFA driver is not a production driver... but a reference and enabling driver, it should/could be managed as just that... a reference baseline driver that any potential user can go and grab the source, or contribute a patch. Nothing more... nothing less. For the release decision, I'll be happy to call a meeting... but we can also handle it via email as well... just let me know. Feedback from all is welcome... but I would request mandatory feedback form the 4 reviewing companies: Samsung, HGST, PMC-Sierra, and Intel. How would you like to proceed? Thanks, Ray [cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles Non-Volatile Memory Solutions Group Intel Corporation Office: 480-554-2600 Mobile: 480-399-0645 HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4274 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 1756 bytes Desc: image002.png URL: ------------------------------ _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/mailman/listinfo/nvmewin End of nvmewin Digest, Vol 49, Issue 4 **************************************

 

 

[http://ext.samsung.net/mailcheck/SeenTimeChecker?do=28bccb0e7a1e0d06eef29fb3c992dbe0ce8eea4993ac5e06313cb48408a29da1bbef98290b9ea6844a835b19b8ec809fc7b41e955949e5c8a728c55b39cc59eacf878f9a26ce15a0] -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.freeman at hgst.com Wed Jan 20 12:50:16 2016 From: thomas.freeman at hgst.com (Thomas Freeman) Date: Wed, 20 Jan 2016 20:50:16 +0000 Subject: [nvmewin] Happy New Year... and status update In-Reply-To: <49158E750348AA499168FD41D889836072588453@fmsmsx117.amr.corp.intel.com> References: <49158E750348AA499168FD41D889836072588453@fmsmsx117.amr.corp.intel.com> Message-ID: Ray, I don't have a strong opinion toward #3, I'm content with option #2 also. Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Wednesday, January 20, 2016 2:45 PM To: suman.p at samsung.com; nvmewin-request at lists.openfabrics.org; nvmewin at lists.openfabrics.org Cc: anshul at samsung.com; MANOJ THAPLIYAL ; tru.nguyen at ssi.samsung.com Subject: Re: [nvmewin] Happy New Year... and status update Hi Suman/Judy, Thank you for your response. Right now, the current vote is... Samsung - Option #2 HGST - Option #3 PMC Sierra - TBD Alex/Kwok, what is your vote/preference on the release options below. Thanks, Ray From: SUMAN PRAKASH B [mailto:suman.p at samsung.com] Sent: Wednesday, January 20, 2016 9:10 AM To: Robles, Raymond C; nvmewin-request at lists.openfabrics.org; nvmewin at lists.openfabrics.org Cc: tru.nguyen at ssi.samsung.com; judy.brock at ssi.samsung.com; MANOJ THAPLIYAL; anshul at samsung.com Subject: Re: Happy New Year... and status update Hello Ray, Samsung votes for Option #2. We push the remaining patches listed and then release in ~Q2 of 2015. And as planned, Samsung will submit the following patches, along with some critical bug fixes. a) Perf Opts (Samsung) b) Win 8.1 Timers (Samsung) c) EOL Read Only (Samsung) And we will be ready with our first patch "Perf Opts" after 5 days of pushing the Namespace management patch to main branch. Please let us know your opinion. Regards, Suman ---------------------------------------------------------------------- Message: 1 Date: Tue, 19 Jan 2016 14:32:45 +0000 From: Judy Brock-SSI > To: "Robles, Raymond C" >, "'nvmewin at lists.openfabrics.org'" > Subject: Re: [nvmewin] Happy New Year... and status update Message-ID: <36E8D38D6B771A4BBDB1C0D800158A51865B7376 at SSIEXCH-MB3.ssi.samsung.com> Content-Type: text/plain; charset="us-ascii" Hi Ray, We are still discussing internally. We will let you know which option we vote for soon! Regards, Judy From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, January 14, 2016 3:55 PM To: 'nvmewin at lists.openfabrics.org' Subject: [nvmewin] Happy New Year... and status update Hello and Happy New Year, I hope everyone had a great holiday season and is off to a great start to the new year! As communicated last month, the patch from HGST for the SCSI multi-initiator changes has been approved and pushed. The holidays slowed down much of the progress on the OFA driver and there were several patches that did not get pushed prior to the end of the year. The list of patches remained to be pushed are as follows... * Namespace Management (Intel) * Perf Opts (Samsung) * Win 8.1 Timers (Samsung) * EOL Read Only (Samsung) * Concurrent channels (Google) The namespace management patch will be sent out for review tomorrow (look for the patch email from Carolyn)... stay tuned!!! However, once this patch is resolved, we as a community will have to make a decision on an official release strategy. The patch process and cadence was significantly slower in 2015 which leaves us with a few options. 1. Release what is in the trunk today (or after the namespace management patch)... and call that the 2015 release (albeit later than expected) 2. In lieu of an official 2015 release, we push the remaining patches listed above... and then release in ~Q2 of 2015. Basically skip a 2015 release and go right into the mid-2016 release. 3. Remove the concept of "official releases" from the OFA Windows NVMe driver and just allow people, companies, and users to pull from the OFA trunk as necessary. For #3 above, my thoughts are that because the OFA driver is not a production driver... but a reference and enabling driver, it should/could be managed as just that... a reference baseline driver that any potential user can go and grab the source, or contribute a patch. Nothing more... nothing less. For the release decision, I'll be happy to call a meeting... but we can also handle it via email as well... just let me know. Feedback from all is welcome... but I would request mandatory feedback form the 4 reviewing companies: Samsung, HGST, PMC-Sierra, and Intel. How would you like to proceed? Thanks, Ray [cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles Non-Volatile Memory Solutions Group Intel Corporation Office: 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: ------------------------------ Message: 2 Date: Tue, 19 Jan 2016 14:41:36 +0000 From: Thomas Freeman > To: "Robles, Raymond C" > Cc: "'nvmewin at lists.openfabrics.org'" > Subject: Re: [nvmewin] Happy New Year... and status update Message-ID: > Content-Type: text/plain; charset="us-ascii" Thanks for the response Ray. I'm fine with option 3. Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com> 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com> From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Friday, January 15, 2016 3:54 PM To: Thomas Freeman > Cc: 'nvmewin at lists.openfabrics.org' > Subject: RE: Happy New Year... and status update Hi Tom, Great questions... here are my thoughts. But I encourage others to chime in as well. Is this purely a question of how the changes are packaged? [RCR] Exactly! I am merely making a suggestion that will ease the burden of having mandatory releases... as well as having to adhere to a schedule that really has no meaning to any particular product since the OFA driver is a reference driver. Much like the Linux community, any vendor can take our baseline and package it up as needed, but for the community itself, it just manages bug fix and feature patches as they come in. Or do any of these options imply what type of fixes/changes will be delivered in the future? i.e. Does choosing option 3 imply that the driver is going into purely maintenance mode? [RCR] Not at all. Option 3 is simply us doing what we've done all along... with the exception of not doing any "official releases". All bug fix and feature patches would still be graciously accepted... and welcome :). Or with that option, would there still be a coordinated effort to release new function along with fixes? [RCR] Exactly... see above responses. Does this answer your questions Tom? Thanks, Ray From: Thomas Freeman [mailto:thomas.freeman at hgst.com] Sent: Friday, January 15, 2016 9:04 AM To: Robles, Raymond C; 'nvmewin at lists.openfabrics.org' Subject: RE: Happy New Year... and status update Ray, Is this purely a question of how the changes are packaged? Or do any of these options imply what type of fixes/changes will be delivered in the future? i.e. Does choosing option 3 imply that the driver is going into purely maintenance mode? Or with that option, would there still be a coordinated effort to release new function along with fixes? Thanks, Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com> 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com> From: nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, January 14, 2016 5:55 PM To: 'nvmewin at lists.openfabrics.org' >> Subject: [nvmewin] Happy New Year... and status update Hello and Happy New Year, I hope everyone had a great holiday season and is off to a great start to the new year! As communicated last month, the patch from HGST for the SCSI multi-initiator changes has been approved and pushed. The holidays slowed down much of the progress on the OFA driver and there were several patches that did not get pushed prior to the end of the year. The list of patches remained to be pushed are as follows... * Namespace Management (Intel) * Perf Opts (Samsung) * Win 8.1 Timers (Samsung) * EOL Read Only (Samsung) * Concurrent channels (Google) The namespace management patch will be sent out for review tomorrow (look for the patch email from Carolyn)... stay tuned!!! However, once this patch is resolved, we as a community will have to make a decision on an official release strategy. The patch process and cadence was significantly slower in 2015 which leaves us with a few options. 1. Release what is in the trunk today (or after the namespace management patch)... and call that the 2015 release (albeit later than expected) 2. In lieu of an official 2015 release, we push the remaining patches listed above... and then release in ~Q2 of 2015. Basically skip a 2015 release and go right into the mid-2016 release. 3. Remove the concept of "official releases" from the OFA Windows NVMe driver and just allow people, companies, and users to pull from the OFA trunk as necessary. For #3 above, my thoughts are that because the OFA driver is not a production driver... but a reference and enabling driver, it should/could be managed as just that... a reference baseline driver that any potential user can go and grab the source, or contribute a patch. Nothing more... nothing less. For the release decision, I'll be happy to call a meeting... but we can also handle it via email as well... just let me know. Feedback from all is welcome... but I would request mandatory feedback form the 4 reviewing companies: Samsung, HGST, PMC-Sierra, and Intel. How would you like to proceed? Thanks, Ray [cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles Non-Volatile Memory Solutions Group Intel Corporation Office: 480-554-2600 Mobile: 480-399-0645 HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4274 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 1756 bytes Desc: image002.png URL: ------------------------------ _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/mailman/listinfo/nvmewin End of nvmewin Digest, Vol 49, Issue 4 **************************************

 

 

[Image removed by sender.] HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ~WRD000.jpg Type: image/jpeg Size: 823 bytes Desc: ~WRD000.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4274 bytes Desc: image001.png URL: From Austin_Bolen at Dell.com Wed Jan 20 13:11:24 2016 From: Austin_Bolen at Dell.com (Austin_Bolen at Dell.com) Date: Wed, 20 Jan 2016 15:11:24 -0600 Subject: [nvmewin] Happy New Year... and status update In-Reply-To: References: <49158E750348AA499168FD41D889836072588453@fmsmsx117.amr.corp.intel.com> Message-ID: Dell - Internal Use - Confidential Dell would also prefer option 2. We like to start with an "official" release that has been through some level of testing and has been WHQL'd and use that as our base. If the official version passes all of our internal validation then we use that as our customer release, else we'll patch locally for our customer release and push the patches back upstream (fork and merge model). This is what we've done for the prior few releases and the model seems to work well. Thanks, Austin From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Thomas Freeman Sent: Wednesday, January 20, 2016 2:50 PM To: Robles, Raymond C; suman.p at samsung.com; nvmewin-request at lists.openfabrics.org; nvmewin at lists.openfabrics.org Cc: anshul at samsung.com; MANOJ THAPLIYAL; tru.nguyen at ssi.samsung.com Subject: Re: [nvmewin] Happy New Year... and status update Ray, I don't have a strong opinion toward #3, I'm content with option #2 also. Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [cid:image001.png at 01D15394.D39900A0] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Wednesday, January 20, 2016 2:45 PM To: suman.p at samsung.com; nvmewin-request at lists.openfabrics.org; nvmewin at lists.openfabrics.org Cc: anshul at samsung.com; MANOJ THAPLIYAL >; tru.nguyen at ssi.samsung.com Subject: Re: [nvmewin] Happy New Year... and status update Hi Suman/Judy, Thank you for your response. Right now, the current vote is... Samsung - Option #2 HGST - Option #3 PMC Sierra - TBD Alex/Kwok, what is your vote/preference on the release options below. Thanks, Ray From: SUMAN PRAKASH B [mailto:suman.p at samsung.com] Sent: Wednesday, January 20, 2016 9:10 AM To: Robles, Raymond C; nvmewin-request at lists.openfabrics.org; nvmewin at lists.openfabrics.org Cc: tru.nguyen at ssi.samsung.com; judy.brock at ssi.samsung.com; MANOJ THAPLIYAL; anshul at samsung.com Subject: Re: Happy New Year... and status update Hello Ray, Samsung votes for Option #2. We push the remaining patches listed and then release in ~Q2 of 2015. And as planned, Samsung will submit the following patches, along with some critical bug fixes. a) Perf Opts (Samsung) b) Win 8.1 Timers (Samsung) c) EOL Read Only (Samsung) And we will be ready with our first patch "Perf Opts" after 5 days of pushing the Namespace management patch to main branch. Please let us know your opinion. Regards, Suman ---------------------------------------------------------------------- Message: 1 Date: Tue, 19 Jan 2016 14:32:45 +0000 From: Judy Brock-SSI > To: "Robles, Raymond C" >, "'nvmewin at lists.openfabrics.org'" > Subject: Re: [nvmewin] Happy New Year... and status update Message-ID: <36E8D38D6B771A4BBDB1C0D800158A51865B7376 at SSIEXCH-MB3.ssi.samsung.com> Content-Type: text/plain; charset="us-ascii" Hi Ray, We are still discussing internally. We will let you know which option we vote for soon! Regards, Judy From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, January 14, 2016 3:55 PM To: 'nvmewin at lists.openfabrics.org' Subject: [nvmewin] Happy New Year... and status update Hello and Happy New Year, I hope everyone had a great holiday season and is off to a great start to the new year! As communicated last month, the patch from HGST for the SCSI multi-initiator changes has been approved and pushed. The holidays slowed down much of the progress on the OFA driver and there were several patches that did not get pushed prior to the end of the year. The list of patches remained to be pushed are as follows... * Namespace Management (Intel) * Perf Opts (Samsung) * Win 8.1 Timers (Samsung) * EOL Read Only (Samsung) * Concurrent channels (Google) The namespace management patch will be sent out for review tomorrow (look for the patch email from Carolyn)... stay tuned!!! However, once this patch is resolved, we as a community will have to make a decision on an official release strategy. The patch process and cadence was significantly slower in 2015 which leaves us with a few options. 1. Release what is in the trunk today (or after the namespace management patch)... and call that the 2015 release (albeit later than expected) 2. In lieu of an official 2015 release, we push the remaining patches listed above... and then release in ~Q2 of 2015. Basically skip a 2015 release and go right into the mid-2016 release. 3. Remove the concept of "official releases" from the OFA Windows NVMe driver and just allow people, companies, and users to pull from the OFA trunk as necessary. For #3 above, my thoughts are that because the OFA driver is not a production driver... but a reference and enabling driver, it should/could be managed as just that... a reference baseline driver that any potential user can go and grab the source, or contribute a patch. Nothing more... nothing less. For the release decision, I'll be happy to call a meeting... but we can also handle it via email as well... just let me know. Feedback from all is welcome... but I would request mandatory feedback form the 4 reviewing companies: Samsung, HGST, PMC-Sierra, and Intel. How would you like to proceed? Thanks, Ray [cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles Non-Volatile Memory Solutions Group Intel Corporation Office: 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: ------------------------------ Message: 2 Date: Tue, 19 Jan 2016 14:41:36 +0000 From: Thomas Freeman > To: "Robles, Raymond C" > Cc: "'nvmewin at lists.openfabrics.org'" > Subject: Re: [nvmewin] Happy New Year... and status update Message-ID: > Content-Type: text/plain; charset="us-ascii" Thanks for the response Ray. I'm fine with option 3. Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com> 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com> From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Friday, January 15, 2016 3:54 PM To: Thomas Freeman > Cc: 'nvmewin at lists.openfabrics.org' > Subject: RE: Happy New Year... and status update Hi Tom, Great questions... here are my thoughts. But I encourage others to chime in as well. Is this purely a question of how the changes are packaged? [RCR] Exactly! I am merely making a suggestion that will ease the burden of having mandatory releases... as well as having to adhere to a schedule that really has no meaning to any particular product since the OFA driver is a reference driver. Much like the Linux community, any vendor can take our baseline and package it up as needed, but for the community itself, it just manages bug fix and feature patches as they come in. Or do any of these options imply what type of fixes/changes will be delivered in the future? i.e. Does choosing option 3 imply that the driver is going into purely maintenance mode? [RCR] Not at all. Option 3 is simply us doing what we've done all along... with the exception of not doing any "official releases". All bug fix and feature patches would still be graciously accepted... and welcome :). Or with that option, would there still be a coordinated effort to release new function along with fixes? [RCR] Exactly... see above responses. Does this answer your questions Tom? Thanks, Ray From: Thomas Freeman [mailto:thomas.freeman at hgst.com] Sent: Friday, January 15, 2016 9:04 AM To: Robles, Raymond C; 'nvmewin at lists.openfabrics.org' Subject: RE: Happy New Year... and status update Ray, Is this purely a question of how the changes are packaged? Or do any of these options imply what type of fixes/changes will be delivered in the future? i.e. Does choosing option 3 imply that the driver is going into purely maintenance mode? Or with that option, would there still be a coordinated effort to release new function along with fixes? Thanks, Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com> 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com> From: nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, January 14, 2016 5:55 PM To: 'nvmewin at lists.openfabrics.org' >> Subject: [nvmewin] Happy New Year... and status update Hello and Happy New Year, I hope everyone had a great holiday season and is off to a great start to the new year! As communicated last month, the patch from HGST for the SCSI multi-initiator changes has been approved and pushed. The holidays slowed down much of the progress on the OFA driver and there were several patches that did not get pushed prior to the end of the year. The list of patches remained to be pushed are as follows... * Namespace Management (Intel) * Perf Opts (Samsung) * Win 8.1 Timers (Samsung) * EOL Read Only (Samsung) * Concurrent channels (Google) The namespace management patch will be sent out for review tomorrow (look for the patch email from Carolyn)... stay tuned!!! However, once this patch is resolved, we as a community will have to make a decision on an official release strategy. The patch process and cadence was significantly slower in 2015 which leaves us with a few options. 1. Release what is in the trunk today (or after the namespace management patch)... and call that the 2015 release (albeit later than expected) 2. In lieu of an official 2015 release, we push the remaining patches listed above... and then release in ~Q2 of 2015. Basically skip a 2015 release and go right into the mid-2016 release. 3. Remove the concept of "official releases" from the OFA Windows NVMe driver and just allow people, companies, and users to pull from the OFA trunk as necessary. For #3 above, my thoughts are that because the OFA driver is not a production driver... but a reference and enabling driver, it should/could be managed as just that... a reference baseline driver that any potential user can go and grab the source, or contribute a patch. Nothing more... nothing less. For the release decision, I'll be happy to call a meeting... but we can also handle it via email as well... just let me know. Feedback from all is welcome... but I would request mandatory feedback form the 4 reviewing companies: Samsung, HGST, PMC-Sierra, and Intel. How would you like to proceed? Thanks, Ray [cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles Non-Volatile Memory Solutions Group Intel Corporation Office: 480-554-2600 Mobile: 480-399-0645 HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4274 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 1756 bytes Desc: image002.png URL: ------------------------------ _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/mailman/listinfo/nvmewin End of nvmewin Digest, Vol 49, Issue 4 **************************************

 

 

[cid:image002.jpg at 01D15394.D39900A0] HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4274 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 823 bytes Desc: image002.jpg URL: From suman.p at samsung.com Wed Jan 27 08:57:33 2016 From: suman.p at samsung.com (SUMAN PRAKASH B) Date: Wed, 27 Jan 2016 16:57:33 +0000 (GMT) Subject: [nvmewin] Review comments for Namespace Management patch Message-ID: <38.D7.05161.DF6F8A65@epcpsbgx4.samsung.com> An HTML attachment was scrubbed... URL: From thomas.freeman at hgst.com Wed Jan 27 10:52:38 2016 From: thomas.freeman at hgst.com (Thomas Freeman) Date: Wed, 27 Jan 2016 18:52:38 +0000 Subject: [nvmewin] HGST's review of patch for namespace management Message-ID: Hi Carolyn, I have some additional comments nvmeInit.c: NVMeInitCallback: line 1808: NN is unsigned so the "<=" should be replaced with "==" if (pAE->controllerIdentifyData.NN == 0) { nvmeStd.c: NVMeIoctlIdentify: line 3060 According to the NVMe 1.2 spec, when CNS is 2, "A list of 1024 namespace IDs is returned". So Databuffersize should be set to 4k. NVMeIoctlIdentify: line 3060 databuffersize needs to be set for other values of cns (e.g. 0x10) or it will fail call to NVMePreparePRP's NVMeCompletionNsAttachment: line 4061; The code works as is, but for correctness sizeof(ADMIN_IDENTIFY_NAMESPACE) should be specified. Also, I'm seeing some incorrect behavior with SCSI Report Luns Here are the steps and the results I'm seeing 1. Create Namespaces 1,2,3,4,5. Attach only NSID 1. 2. Disable/re-enable the device 3. Attach NSID's 3 & 5 (now 1,2,3,4,5 are existing NSIDs, 1,3,5 are attached NSIDs) 4. Report LUNs results: Length 0x38, Lun List 0, 2, 4, 0, 0, 0, 0 - Should be 0x18/0, 2, 4 5. Disable/re-enable the device 6. Report LUNs results: Length 0x28 Lun list 0,1,2,0,0 - Should be 0x18/0,1,2 7. Namespace delete of NSID 1. 8. Report LUNs results: Length 0x20 Lun list 1,2,0,0 - Invalid. First LUN must be 0. From the SNTL 1.5 spec "The list shall contain logical unit numbers corresponding to namespaces present on the device with a Namespace Capacity (NCAP) field of the Identify Namespace Structure set to greater than 0h. Logical unit numbers shall begin with 0 and have a maximum value of NN-1, where NN is the Number of Namespaces field within Identify Controller Data Structure. " 9. Disable/re-enable the device 10. Report LUNs results: Length 0x20 Lun list 0,1,0,0 - Should be 0x10/0,1 Thanks, Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Foster, Carolyn D Sent: Friday, January 15, 2016 5:57 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Patch with changes for Namespace Management Hi all, This patch includes changes to support Namespace Management updates from the NVMe specification 1.2. This patch implements some fixes for handling non-continuous namespaces, adds handling for attached and detached namespaces, and implements new IOCTLs to create, delete, attach and detach namespaces. I have made a detailed overview of the changes in the text file in the attached zip file, the contents are also copied here below. Password is intelnvme Please let me know if you have any questions. Carolyn Foster This patch includes changes to support Namespace management, including create, delete, attach and detach namespace operations. The new functionality in this patch was tested using proprietary tools. We tested on Server 2008 R2, Server 2012 R2 and Windows 8.1 ****************** Design Assumptions ****************** 1. The numbering of namespaces need not be consecutive. 2. The namespace ID can be any number between 1 and 2^32. 3. A namespace is considered "active" only when it is created and attached to this controller. 4. A detached namespace, or one that is just created but not yet attached is considered "inactive". 5. A non-existent, or deleted namespace is considered "invalid". 6. An active namespace will result in one (and only one) "Online" LUN. 7. Assuming single-host, and single-controller NVMe system. ********************* Architecture Overview ********************* There are four new IOCTLs for namespace management, Create, Delete, Attach and Detach. An attached namespace will result in a visible LUN to the Windows OS. The LUN extension table has been updated to have a Namespace status: typedef enum _NS_STATUS { INVALID = 0, //Namespace ID does not exist (not known to controller). INACTIVE, //Namespace is created, but not attached to controller. ATTACHED //Namespace is created and attached to controller. } NS_STATUS; In order to properly build the LUN extension table during initialization, we made changes to identify all namespaces, and to determine each namespace's status. These changes include new states in the Init State Machine NVMeRnningWaitOnListAttachedNs and NVMeRunningWaitOnListExistingNs. The updated state machine steps are as follows: 1. Send an Identify Namespace command with CNS set to 02h. This should return a list of all active (created and attached) namespaces. 2. Go through the list and update LUN extension entries accordingly, one entry for each namespace. Set all LUN status to online. 3. Send an Identify Namespace command with CNS set to 10h. This should return a list of all existing namespaces in the system, active and inactive. 4. Go through the list. 5. If a corresponding LUN entry exists, skip this step, as this must have been an active namespace that was covered in previous steps. LUN extension entries are populated as follows: When a namespace is created: - namespaceId is set. - nsStatus is set to "INACTIVE" - slotStatus is set to "FREE" - identifyData is partially set When a namespace is attached: - drive is pulled for namespace identify - identifyData is set accordingly - nsStatus is set to "ATTACHED" - slotStatus is set to "ONLINE" - ReadOnly is set to FALSE When a namespace is detached: - nsStatus is set to "INACTIVE" - slotStatus is set to "FREE" - ReadOnly is set to TRUE When a namespace is deleted: - The entire LUN extension entry is set to 0. There are also new reasons for the LUN to be offline: typedef enum _LUN_OFFLINE_REASON { NOT_OFFLINE, FORMAT_IN_PROGRESS, DETACH_IN_PROGRESS, DELETE_IN_PROGRESS // Add more as needed } LUN_OFFLINE_REASON; When delete or detach requests are made, the driver will call StorportDeviceBusy to pause incoming requests, and the LUN is marked as offline with the appropriate reason. When a user tries to delete an attached namespace, the driver will first send a detach command, and then the delete command. ***************** Known Limitations ***************** 1. If no namepsaces are present, the driver will fail to load. 2. If an error happens on any one namespace during initialization the driver will fail to load. The handling for these two scenarios could be strengthened and improved, which we did not get to in this patch. Western Digital Corporation (and its subsidiaries) E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of WDC and/or its affiliates, and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4274 bytes Desc: image001.png URL: From thomas.freeman at hgst.com Fri Jan 29 07:40:39 2016 From: thomas.freeman at hgst.com (Thomas Freeman) Date: Fri, 29 Jan 2016 15:40:39 +0000 Subject: [nvmewin] HGST's review of patch for namespace management In-Reply-To: References: Message-ID: Hi Carolyn, During my testing, I saw a few more items that should be addressed. I know a few of these are not changes you made, but they are issues I saw while stepping through the code. nvmeInit.c NVMeSetFeaturesCompletion:Line 1459 should set pAE->DriverState.NumQueuesSet = TRUE; NVMeSetFeaturesCompletion:line 1496 Check should validate that the SCT is GENERIC_COMMAND_STATUS NVMeSetFeaturesCompletion:line 1500 Also need to check for SC==INVALID_NAMESPACE_OR_FORMAT. In my testing, that is the value I saw going down this path NVMeSetFeaturesCompletion:line 1513 For the case where NS Mgmt is not supported, nsStatus should be set to ATTACHED if (!pAE->controllerIdentifyData.OACS.SupportsNamespaceMgmtAndAttachment) { pLunExt->nsStatus = ATTACHED; } NVMeSetFeaturesCompletion:line 1518 In the case where NS mgmt is not supported, nsStatus will be "INVALID" } else if ((INACTIVE == pLunExt->nsStatus) || (INVALID == pLunExt->nsStatus)) NVMeAccessLbaRangeEntry:line 2361 size should be a full page, not sizeof LBA RANGE entry nvmeStd.c NVMeIoctlSetGetFeatures:line 3197 dataBufferSize should be set to a full page (LBA RANGE) Also, this is required to be contiguous memory. I don't think we can guarantee that with the IOCTL databuffer. During testing (with devices that do and do not support NS Mgmt), I ran into issues when I had 0 namespaces or a single detached namespace. Below are some of my suggestions on possible ways to address this nvmeInit.c NVMESetFeaturesCompletion:line 1490 When there are no namespaces (NumKnowNamespaces is 0), after setting int coalescing and number of queues, there is no need to get LBA range types. Go directly to NVMeWaitOnSetupQueues if (pAE->DriverState.TtlLbaRangeExamined < pAE->DriverState.NumKnownNamespaces) { pAE->DriverState.NextDriverState = NVMeWaitOnSetFeatures; } else { /* There are no valid luns, so skip set features steps that */ /* are issued to namespaces */ pAE->DriverState.NextDriverState = NVMeWaitOnSetupQueues; } NVMeInitCallback:line 1808 In my testing, going down this path left the controller disabled. Instead of calling FatalError, go to NVMeWaitOnSetFeatures. if (pAE->controllerIdentifyData.NN == 0) { pAE->DriverState.NextDriverState = NVMeWaitOnSetFeatures; pAE->visibleLuns = 0; } NVMeInitCallback:line 1884 After processing the attached and existing NS lists, if there are no NS's, skip the step to review Identify NS's and go directly to NVMeWaitOnSetFeatures. if (pAE->DriverState.NumKnownNamespaces == 0) { pAE->DriverState.NextDriverState = NVMeWaitOnSetFeatures; } else { pAE->DriverState.NextDriverState = NVMeWaitOnIdentifyNS; } Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Thomas Freeman Sent: Wednesday, January 27, 2016 12:53 PM To: Foster, Carolyn D ; nvmewin at lists.openfabrics.org Subject: [nvmewin] HGST's review of patch for namespace management Hi Carolyn, I have some additional comments nvmeInit.c: NVMeInitCallback: line 1808: NN is unsigned so the "<=" should be replaced with "==" if (pAE->controllerIdentifyData.NN == 0) { nvmeStd.c: NVMeIoctlIdentify: line 3060 According to the NVMe 1.2 spec, when CNS is 2, "A list of 1024 namespace IDs is returned". So Databuffersize should be set to 4k. NVMeIoctlIdentify: line 3060 databuffersize needs to be set for other values of cns (e.g. 0x10) or it will fail call to NVMePreparePRP's NVMeCompletionNsAttachment: line 4061; The code works as is, but for correctness sizeof(ADMIN_IDENTIFY_NAMESPACE) should be specified. Also, I'm seeing some incorrect behavior with SCSI Report Luns Here are the steps and the results I'm seeing 1. Create Namespaces 1,2,3,4,5. Attach only NSID 1. 2. Disable/re-enable the device 3. Attach NSID's 3 & 5 (now 1,2,3,4,5 are existing NSIDs, 1,3,5 are attached NSIDs) 4. Report LUNs results: Length 0x38, Lun List 0, 2, 4, 0, 0, 0, 0 - Should be 0x18/0, 2, 4 5. Disable/re-enable the device 6. Report LUNs results: Length 0x28 Lun list 0,1,2,0,0 - Should be 0x18/0,1,2 7. Namespace delete of NSID 1. 8. Report LUNs results: Length 0x20 Lun list 1,2,0,0 - Invalid. First LUN must be 0. From the SNTL 1.5 spec "The list shall contain logical unit numbers corresponding to namespaces present on the device with a Namespace Capacity (NCAP) field of the Identify Namespace Structure set to greater than 0h. Logical unit numbers shall begin with 0 and have a maximum value of NN-1, where NN is the Number of Namespaces field within Identify Controller Data Structure. " 9. Disable/re-enable the device 10. Report LUNs results: Length 0x20 Lun list 0,1,0,0 - Should be 0x10/0,1 Thanks, Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Foster, Carolyn D Sent: Friday, January 15, 2016 5:57 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Patch with changes for Namespace Management Hi all, This patch includes changes to support Namespace Management updates from the NVMe specification 1.2. This patch implements some fixes for handling non-continuous namespaces, adds handling for attached and detached namespaces, and implements new IOCTLs to create, delete, attach and detach namespaces. I have made a detailed overview of the changes in the text file in the attached zip file, the contents are also copied here below. Password is intelnvme Please let me know if you have any questions. Carolyn Foster This patch includes changes to support Namespace management, including create, delete, attach and detach namespace operations. The new functionality in this patch was tested using proprietary tools. We tested on Server 2008 R2, Server 2012 R2 and Windows 8.1 ****************** Design Assumptions ****************** 1. The numbering of namespaces need not be consecutive. 2. The namespace ID can be any number between 1 and 2^32. 3. A namespace is considered "active" only when it is created and attached to this controller. 4. A detached namespace, or one that is just created but not yet attached is considered "inactive". 5. A non-existent, or deleted namespace is considered "invalid". 6. An active namespace will result in one (and only one) "Online" LUN. 7. Assuming single-host, and single-controller NVMe system. ********************* Architecture Overview ********************* There are four new IOCTLs for namespace management, Create, Delete, Attach and Detach. An attached namespace will result in a visible LUN to the Windows OS. The LUN extension table has been updated to have a Namespace status: typedef enum _NS_STATUS { INVALID = 0, //Namespace ID does not exist (not known to controller). INACTIVE, //Namespace is created, but not attached to controller. ATTACHED //Namespace is created and attached to controller. } NS_STATUS; In order to properly build the LUN extension table during initialization, we made changes to identify all namespaces, and to determine each namespace's status. These changes include new states in the Init State Machine NVMeRnningWaitOnListAttachedNs and NVMeRunningWaitOnListExistingNs. The updated state machine steps are as follows: 1. Send an Identify Namespace command with CNS set to 02h. This should return a list of all active (created and attached) namespaces. 2. Go through the list and update LUN extension entries accordingly, one entry for each namespace. Set all LUN status to online. 3. Send an Identify Namespace command with CNS set to 10h. This should return a list of all existing namespaces in the system, active and inactive. 4. Go through the list. 5. If a corresponding LUN entry exists, skip this step, as this must have been an active namespace that was covered in previous steps. LUN extension entries are populated as follows: When a namespace is created: - namespaceId is set. - nsStatus is set to "INACTIVE" - slotStatus is set to "FREE" - identifyData is partially set When a namespace is attached: - drive is pulled for namespace identify - identifyData is set accordingly - nsStatus is set to "ATTACHED" - slotStatus is set to "ONLINE" - ReadOnly is set to FALSE When a namespace is detached: - nsStatus is set to "INACTIVE" - slotStatus is set to "FREE" - ReadOnly is set to TRUE When a namespace is deleted: - The entire LUN extension entry is set to 0. There are also new reasons for the LUN to be offline: typedef enum _LUN_OFFLINE_REASON { NOT_OFFLINE, FORMAT_IN_PROGRESS, DETACH_IN_PROGRESS, DELETE_IN_PROGRESS // Add more as needed } LUN_OFFLINE_REASON; When delete or detach requests are made, the driver will call StorportDeviceBusy to pause incoming requests, and the LUN is marked as offline with the appropriate reason. When a user tries to delete an attached namespace, the driver will first send a detach command, and then the delete command. ***************** Known Limitations ***************** 1. If no namepsaces are present, the driver will fail to load. 2. If an error happens on any one namespace during initialization the driver will fail to load. The handling for these two scenarios could be strengthened and improved, which we did not get to in this patch. Western Digital Corporation (and its subsidiaries) E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of WDC and/or its affiliates, and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. Western Digital Corporation (and its subsidiaries) E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of WDC and/or its affiliates, and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4274 bytes Desc: image001.png URL: From carolyn.d.foster at intel.com Fri Jan 29 08:04:22 2016 From: carolyn.d.foster at intel.com (Foster, Carolyn D) Date: Fri, 29 Jan 2016 16:04:22 +0000 Subject: [nvmewin] HGST's review of patch for namespace management In-Reply-To: References: Message-ID: Hi Tom, thank you for the feedback, I will review your comments and make appropriate changes. I will try to get the updates out in the next two weeks. Carolyn From: Thomas Freeman [mailto:thomas.freeman at hgst.com] Sent: Friday, January 29, 2016 8:41 AM To: Foster, Carolyn D ; nvmewin at lists.openfabrics.org Subject: RE: HGST's review of patch for namespace management Hi Carolyn, During my testing, I saw a few more items that should be addressed. I know a few of these are not changes you made, but they are issues I saw while stepping through the code. nvmeInit.c NVMeSetFeaturesCompletion:Line 1459 should set pAE->DriverState.NumQueuesSet = TRUE; NVMeSetFeaturesCompletion:line 1496 Check should validate that the SCT is GENERIC_COMMAND_STATUS NVMeSetFeaturesCompletion:line 1500 Also need to check for SC==INVALID_NAMESPACE_OR_FORMAT. In my testing, that is the value I saw going down this path NVMeSetFeaturesCompletion:line 1513 For the case where NS Mgmt is not supported, nsStatus should be set to ATTACHED if (!pAE->controllerIdentifyData.OACS.SupportsNamespaceMgmtAndAttachment) { pLunExt->nsStatus = ATTACHED; } NVMeSetFeaturesCompletion:line 1518 In the case where NS mgmt is not supported, nsStatus will be "INVALID" } else if ((INACTIVE == pLunExt->nsStatus) || (INVALID == pLunExt->nsStatus)) NVMeAccessLbaRangeEntry:line 2361 size should be a full page, not sizeof LBA RANGE entry nvmeStd.c NVMeIoctlSetGetFeatures:line 3197 dataBufferSize should be set to a full page (LBA RANGE) Also, this is required to be contiguous memory. I don't think we can guarantee that with the IOCTL databuffer. During testing (with devices that do and do not support NS Mgmt), I ran into issues when I had 0 namespaces or a single detached namespace. Below are some of my suggestions on possible ways to address this nvmeInit.c NVMESetFeaturesCompletion:line 1490 When there are no namespaces (NumKnowNamespaces is 0), after setting int coalescing and number of queues, there is no need to get LBA range types. Go directly to NVMeWaitOnSetupQueues if (pAE->DriverState.TtlLbaRangeExamined < pAE->DriverState.NumKnownNamespaces) { pAE->DriverState.NextDriverState = NVMeWaitOnSetFeatures; } else { /* There are no valid luns, so skip set features steps that */ /* are issued to namespaces */ pAE->DriverState.NextDriverState = NVMeWaitOnSetupQueues; } NVMeInitCallback:line 1808 In my testing, going down this path left the controller disabled. Instead of calling FatalError, go to NVMeWaitOnSetFeatures. if (pAE->controllerIdentifyData.NN == 0) { pAE->DriverState.NextDriverState = NVMeWaitOnSetFeatures; pAE->visibleLuns = 0; } NVMeInitCallback:line 1884 After processing the attached and existing NS lists, if there are no NS's, skip the step to review Identify NS's and go directly to NVMeWaitOnSetFeatures. if (pAE->DriverState.NumKnownNamespaces == 0) { pAE->DriverState.NextDriverState = NVMeWaitOnSetFeatures; } else { pAE->DriverState.NextDriverState = NVMeWaitOnIdentifyNS; } Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Thomas Freeman Sent: Wednesday, January 27, 2016 12:53 PM To: Foster, Carolyn D >; nvmewin at lists.openfabrics.org Subject: [nvmewin] HGST's review of patch for namespace management Hi Carolyn, I have some additional comments nvmeInit.c: NVMeInitCallback: line 1808: NN is unsigned so the "<=" should be replaced with "==" if (pAE->controllerIdentifyData.NN == 0) { nvmeStd.c: NVMeIoctlIdentify: line 3060 According to the NVMe 1.2 spec, when CNS is 2, "A list of 1024 namespace IDs is returned". So Databuffersize should be set to 4k. NVMeIoctlIdentify: line 3060 databuffersize needs to be set for other values of cns (e.g. 0x10) or it will fail call to NVMePreparePRP's NVMeCompletionNsAttachment: line 4061; The code works as is, but for correctness sizeof(ADMIN_IDENTIFY_NAMESPACE) should be specified. Also, I'm seeing some incorrect behavior with SCSI Report Luns Here are the steps and the results I'm seeing 1. Create Namespaces 1,2,3,4,5. Attach only NSID 1. 2. Disable/re-enable the device 3. Attach NSID's 3 & 5 (now 1,2,3,4,5 are existing NSIDs, 1,3,5 are attached NSIDs) 4. Report LUNs results: Length 0x38, Lun List 0, 2, 4, 0, 0, 0, 0 - Should be 0x18/0, 2, 4 5. Disable/re-enable the device 6. Report LUNs results: Length 0x28 Lun list 0,1,2,0,0 - Should be 0x18/0,1,2 7. Namespace delete of NSID 1. 8. Report LUNs results: Length 0x20 Lun list 1,2,0,0 - Invalid. First LUN must be 0. From the SNTL 1.5 spec "The list shall contain logical unit numbers corresponding to namespaces present on the device with a Namespace Capacity (NCAP) field of the Identify Namespace Structure set to greater than 0h. Logical unit numbers shall begin with 0 and have a maximum value of NN-1, where NN is the Number of Namespaces field within Identify Controller Data Structure. " 9. Disable/re-enable the device 10. Report LUNs results: Length 0x20 Lun list 0,1,0,0 - Should be 0x10/0,1 Thanks, Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Foster, Carolyn D Sent: Friday, January 15, 2016 5:57 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Patch with changes for Namespace Management Hi all, This patch includes changes to support Namespace Management updates from the NVMe specification 1.2. This patch implements some fixes for handling non-continuous namespaces, adds handling for attached and detached namespaces, and implements new IOCTLs to create, delete, attach and detach namespaces. I have made a detailed overview of the changes in the text file in the attached zip file, the contents are also copied here below. Password is intelnvme Please let me know if you have any questions. Carolyn Foster This patch includes changes to support Namespace management, including create, delete, attach and detach namespace operations. The new functionality in this patch was tested using proprietary tools. We tested on Server 2008 R2, Server 2012 R2 and Windows 8.1 ****************** Design Assumptions ****************** 1. The numbering of namespaces need not be consecutive. 2. The namespace ID can be any number between 1 and 2^32. 3. A namespace is considered "active" only when it is created and attached to this controller. 4. A detached namespace, or one that is just created but not yet attached is considered "inactive". 5. A non-existent, or deleted namespace is considered "invalid". 6. An active namespace will result in one (and only one) "Online" LUN. 7. Assuming single-host, and single-controller NVMe system. ********************* Architecture Overview ********************* There are four new IOCTLs for namespace management, Create, Delete, Attach and Detach. An attached namespace will result in a visible LUN to the Windows OS. The LUN extension table has been updated to have a Namespace status: typedef enum _NS_STATUS { INVALID = 0, //Namespace ID does not exist (not known to controller). INACTIVE, //Namespace is created, but not attached to controller. ATTACHED //Namespace is created and attached to controller. } NS_STATUS; In order to properly build the LUN extension table during initialization, we made changes to identify all namespaces, and to determine each namespace's status. These changes include new states in the Init State Machine NVMeRnningWaitOnListAttachedNs and NVMeRunningWaitOnListExistingNs. The updated state machine steps are as follows: 1. Send an Identify Namespace command with CNS set to 02h. This should return a list of all active (created and attached) namespaces. 2. Go through the list and update LUN extension entries accordingly, one entry for each namespace. Set all LUN status to online. 3. Send an Identify Namespace command with CNS set to 10h. This should return a list of all existing namespaces in the system, active and inactive. 4. Go through the list. 5. If a corresponding LUN entry exists, skip this step, as this must have been an active namespace that was covered in previous steps. LUN extension entries are populated as follows: When a namespace is created: - namespaceId is set. - nsStatus is set to "INACTIVE" - slotStatus is set to "FREE" - identifyData is partially set When a namespace is attached: - drive is pulled for namespace identify - identifyData is set accordingly - nsStatus is set to "ATTACHED" - slotStatus is set to "ONLINE" - ReadOnly is set to FALSE When a namespace is detached: - nsStatus is set to "INACTIVE" - slotStatus is set to "FREE" - ReadOnly is set to TRUE When a namespace is deleted: - The entire LUN extension entry is set to 0. There are also new reasons for the LUN to be offline: typedef enum _LUN_OFFLINE_REASON { NOT_OFFLINE, FORMAT_IN_PROGRESS, DETACH_IN_PROGRESS, DELETE_IN_PROGRESS // Add more as needed } LUN_OFFLINE_REASON; When delete or detach requests are made, the driver will call StorportDeviceBusy to pause incoming requests, and the LUN is marked as offline with the appropriate reason. When a user tries to delete an attached namespace, the driver will first send a detach command, and then the delete command. ***************** Known Limitations ***************** 1. If no namepsaces are present, the driver will fail to load. 2. If an error happens on any one namespace during initialization the driver will fail to load. The handling for these two scenarios could be strengthened and improved, which we did not get to in this patch. Western Digital Corporation (and its subsidiaries) E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of WDC and/or its affiliates, and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. Western Digital Corporation (and its subsidiaries) E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of WDC and/or its affiliates, and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4274 bytes Desc: image001.png URL: From carolyn.d.foster at intel.com Fri Jan 29 08:05:34 2016 From: carolyn.d.foster at intel.com (Foster, Carolyn D) Date: Fri, 29 Jan 2016 16:05:34 +0000 Subject: [nvmewin] Review comments for Namespace Management patch In-Reply-To: <58.D7.05161.EF6F8A65@epcpsbgx4.samsung.com> References: <58.D7.05161.EF6F8A65@epcpsbgx4.samsung.com> Message-ID: Hi Suman, Thank you for the feedback. I will review your comments and make the appropriate changes. I will try to send the updates out for review in the next two weeks. Carolyn From: SUMAN PRAKASH B [mailto:suman.p at samsung.com] Sent: Wednesday, January 27, 2016 9:58 AM To: nvmewin-request at lists.openfabrics.org; nvmewin at lists.openfabrics.org; Foster, Carolyn D ; Robles, Raymond C Cc: judy.brock at ssi.samsung.com; tru.nguyen at ssi.samsung.com; MANOJ THAPLIYAL ; anshul at samsung.com Subject: Review comments for Namespace Management patch Hi Carolyn, Please find below our Review comments and Queries. Review Comments: 1. Function: NVMeIoctlNamespaceMgmt() Line no: 4005 File: nvmeStd.c In the NVMeIoctlNamespaceMgmt() function, the namesapce status verification can be done only incase of NAMESPACE_MANAGEMENT_DELETE as for NAMESPACE_MANAGEMENT_CREATE, the NSID value is reserved. NVMeGetNamespaceStatusAndSlot(pDevExt, currentNSID, &lunId); This function can be moved inside the below condition. if (pNsMgmtDW10->SEL == NAMESPACE_MANAGEMENT_DELETE) { } 2. Function: NVMeIoctlNamespaceMgmt() Line no: 4017 File: nvmeStd.c The DataBuffer(pNvmePtIoctl->DataBuffer) may not be allocated any memory as no data structure required for NAMESPACE_MANAGEMENT_DELETE operation. pNsCtrlsList = (PNVMe_CONTROLLER_LIST)&pNvmePtIoctl->DataBuffer; It is good to allocate memory for pNsCtrlsList and free the memory after command completion. 3. Function: NVMeCompletionNsAttachment() Line No: 4138 File: nvmeStd.c It is safe to set SEL field to NAMESPACE_MANAGEMENT_DELETE in the pNsMgmtCmd structure. 4. Function: NVMeIoctlNamespaceAttachment() Line no: 3931 File: nvmeStd.c The StorPortNotification(BusChangeDetected, pDevExt); has been called twice while performing the NAMESPACE DELETE. This is for the below sequence of operations. a. Create Namespace b. Attach Namespace c. Delete Namespace The overall execution flow looks as below. 1) Namespace Delete command issued. 2) Set: pLunExt->slotStatus = OFFLINE; pLunExt->offlineReason = DELETE_IN_PROGRESS; 3) StorPortNotification(BusChangeDetected, pDevExt); 4) Namespace Detach Command Issued 5) Detach Command Success 6) Set: pLunExt->nsStatus = INACTIVE; pLunExt->slotStatus = FREE; pLunExt->ReadOnly = TRUE; 7) pDevExt->visibleLuns--; 8) StorPortNotification(BusChangeDetected, pDevExt); 9) Delete Command Issued 10)Delete Command Success 11) Set Lun Extn Table to zero The same behavior observed while executing NAMESPACE DETACH command. This is for the below sequence of operations. a. Create Namespace b. Attach Namespace c. Detach Namespace The overall execution flow looks as below. 1) Namespace Detach command issued. 2) Set: pLunExt->slotStatus = OFFLINE; pLunExt->offlineReason = DETACH_IN_PROGRESS; 3) StorPortNotification(BusChangeDetected, pDevExt); 4) Detach Command Success 5) Set: pLunExt->nsStatus = INACTIVE; pLunExt->slotStatus = FREE; pLunExt->ReadOnly = TRUE; pLunExt->OfflineReason = NOT_OFFLINE; 6) pDevExt->visibleLuns--; 7) StorPortNotification(BusChangeDetected, pDevExt); This StorPortNotification() call of multiple times can be avoided. Queries: 1) Looks like The Identify namespace, set feature/get feature commands during the init state machine have been sent to inactive namespaces also. For example one of the below check condition, leads to the above issue. This has to be taken care in all the scenario. Function: NVMeSetFeaturesCompletion() Line no: 1631 File: nvmeInit.c if (pAE->DriverState.TtlLbaRangeExamined == pAE->DriverState.NumKnownNamespaces) { /* We have called identify namespace as well as get/set * features for each of the NN namespaces that exist. * Move on to the next state in the state machine. */ pAE->visibleLuns = pAE->DriverState.VisibleNamespacesExamined; pAE->DriverState.NextDriverState = NVMeWaitOnSetupQueues; } Could you please confirm is it required to issue commands to the inactive namespaces also? If not, we can keep track of active namespaces and issue commands to only those namespaces. 2) Function: NVMeCompletionNsAttachment() Line no: 4099 File: nvmeStd.c Could you please confirm if its a Identify Controller or Identify Namespace commands? If this is Identify Controller command, the NSID need not be set and CNS should be mentioned. If this is Identify Namespace command, then size of PRP preparation should not be sizeof(ADMIN_IDENTIFY_CONTROLLER) at line no: 4102 Thanks, Suman ---------------------------------------------------------------------- Message: 1 Date: Fri, 15 Jan 2016 23:57:26 +0000 From: "Foster, Carolyn D" > To: "nvmewin at lists.openfabrics.org" > Subject: [nvmewin] Patch with changes for Namespace Management Message-ID: > Content-Type: text/plain; charset="us-ascii" Hi all, This patch includes changes to support Namespace Management updates from the NVMe specification 1.2. This patch implements some fixes for handling non-continuous namespaces, adds handling for attached and detached namespaces, and implements new IOCTLs to create, delete, attach and detach namespaces. I have made a detailed overview of the changes in the text file in the attached zip file, the contents are also copied here below. Password is intelnvme Please let me know if you have any questions. Carolyn Foster This patch includes changes to support Namespace management, including create, delete, attach and detach namespace operations. The new functionality in this patch was tested using proprietary tools. We tested on Server 2008 R2, Server 2012 R2 and Windows 8.1 ****************** Design Assumptions ****************** 1. The numbering of namespaces need not be consecutive. 2. The namespace ID can be any number between 1 and 2^32. 3. A namespace is considered "active" only when it is created and attached to this controller. 4. A detached namespace, or one that is just created but not yet attached is considered "inactive". 5. A non-existent, or deleted namespace is considered "invalid". 6. An active namespace will result in one (and only one) "Online" LUN. 7. Assuming single-host, and single-controller NVMe system. ********************* Architecture Overview ********************* There are four new IOCTLs for namespace management, Create, Delete, Attach and Detach. An attached namespace will result in a visible LUN to the Windows OS. The LUN extension table has been updated to have a Namespace status: typedef enum _NS_STATUS { INVALID = 0, //Namespace ID does not exist (not known to controller). INACTIVE, //Namespace is created, but not attached to controller. ATTACHED //Namespace is created and attached to controller. } NS_STATUS; In order to properly build the LUN extension table during initialization, we made changes to identify all namespaces, and to determine each namespace's status. These changes include new states in the Init State Machine NVMeRnningWaitOnListAttachedNs and NVMeRunningWaitOnListExistingNs. The updated state machine steps are as follows: 1. Send an Identify Namespace command with CNS set to 02h. This should return a list of all active (created and attached) namespaces. 2. Go through the list and update LUN extension entries accordingly, one entry for each namespace. Set all LUN status to online. 3. Send an Identify Namespace command with CNS set to 10h. This should return a list of all existing namespaces in the system, active and inactive. 4. Go through the list. 5. If a corresponding LUN entry exists, skip this step, as this must have been an active namespace that was covered in previous steps. LUN extension entries are populated as follows: When a namespace is created: - namespaceId is set. - nsStatus is set to "INACTIVE" - slotStatus is set to "FREE" - identifyData is partially set When a namespace is attached: - drive is pulled for namespace identify - identifyData is set accordingly - nsStatus is set to "ATTACHED" - slotStatus is set to "ONLINE" - ReadOnly is set to FALSE When a namespace is detached: - nsStatus is set to "INACTIVE" - slotStatus is set to "FREE" - ReadOnly is set to TRUE When a namespace is deleted: - The entire LUN extension entry is set to 0. There are also new reasons for the LUN to be offline: typedef enum _LUN_OFFLINE_REASON { NOT_OFFLINE, FORMAT_IN_PROGRESS, DETACH_IN_PROGRESS, DELETE_IN_PROGRESS // Add more as needed } LUN_OFFLINE_REASON; When delete or detach requests are made, the driver will call StorportDeviceBusy to pause incoming requests, and the LUN is marked as offline with the appropriate reason. When a user tries to delete an attached namespace, the driver will first send a detach command, and then the delete command. ***************** Known Limitations ***************** 1. If no namepsaces are present, the driver will fail to load. 2. If an error happens on any one namespace during initialization the driver will fail to load. The handling for these two scenarios could be strengthened and improved, which we did not get to in this patch. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IntelNamespaceManagementV1.zip Type: application/x-zip-compressed Size: 222253 bytes Desc: IntelNamespaceManagementV1.zip URL: ------------------------------ _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/mailman/listinfo/nvmewin End of nvmewin Digest, Vol 49, Issue 3 **************************************

 

 

[http://ext.samsung.net/mailcheck/SeenTimeChecker?do=28bccb0e7a1e0d06003ec0f993c867c045ed77d46f93657db8a3fd6b4a260c0ed33a9d35f6e1735f20a30c65ae77ad69c7b41e955949e5c8a728c55b39cc59eacf878f9a26ce15a0] -------------- next part -------------- An HTML attachment was scrubbed... URL: