[nvmewin] Handling pending commands when processing Format [changing from NVMe WG dist. list to OFA NVMe Windows Driver dist. list]

[Judy Brock-SSI]

Hi Ray,
    [Ray wrote]  Let me know if this answers your question.
I don’t think it does. What I wrote below I think was pretty much the same as what you wrote  - or at least that was my intention ☺.
However, the piece I couldn’t explain (cause I haven’t looked into it) is how the driver holds off the beginning of the actual format NVM operation till whatever old IOs that were already in progress for the namespace(s) before the format op request was received are completed back to the caller, aborted, or whatever -  so there are no old live requests hanging around, still in the driver , before the format op begins.
In other words, does the driver hold off starting the format cmd till the outstanding IOs are completed? Or do we perhaps just drop them on the floor and let the OS figure out that those requests are permanently lost/gone due to the LUNs having disappeared (my guess is, the latter is what we do)? Or do we try to abort them all? And so on.
So again, we do understand how to get the OS to avoid sending new I/O requests to stale namespaces but how exactly are the old I/O reqs (those existing at the time the format request comes in ) handled?
At least that is my current question ☺
Thanks,
Judy


From: Robles, Raymond C [mailto:raymond.c.robles at intel.com]
Sent: Thursday, April 18, 2013 2:46 PM
To: Judy Brock-SSI; WONMOON CHEON; ???; nvmewin at lists.openfabrics.org
Subject: RE: RE: Handling pending commands when processing Format [changing from NVMe WG dist. list to OFA NVMe Windows Driver dist. list]

Hello Judy/Wonmoon,
Sorry for the late response. The “hot remove” state is just a state that we enter when the driver receives a Format command.  Basically, this state will remove the namespace(s) from the topology by calling StorPortNotification() with BusChangeDetected.  This will remove the “SCSI target/disk” associated with each namespace form the OS (because Storport will re-enumerate the controller and the driver will not expose the namespaces about to be formatted) so that the format can occur on the relevant namespaces.
By signaling Windows that the namespaces have been “removed”, all I/O will be stopped by the OS.  Then the format can complete.  Once the format is complete, we perform the opposite action to “hot add” the namespace back into the topology by calling StorPortNotification() with BusChangeDetected… only this time, we will surface the namespace(s) again when Storport re-enumerates.
Not queues are deleted in this state, no memory is de-allocated, and nothing else changes about the namespace.  This is simply the first step (in a 3 step sequence) when formatting a namespace as we cannot format a namespace while the OS is aware of its presence and could be potentially sending I/O to a stale namespace config (i.e. changing LBA/sector size).
Let me know if this answers your question.
Thanks,
Ray

From: Judy Brock-SSI [mailto:judy.brock at ssi.samsung.com]
Sent: Wednesday, April 17, 2013 6:21 AM
To: WONMOON CHEON; 강미경; technical at nvmexpress.org<mailto:technical at nvmexpress.org>
Subject: RE: RE: Handling pending commands when processing Format

  >>Would you elaborate more about  the "hot-remove" state? In this state, do you mean that all the IO SQ/CQs are deleted? Or, waiting for completions of all the outstanding IOs?

The IO SQ/CQs are definitely NOT deleted. I would need to look more closely through the driver code to see how IOs previously sent to the namespaces which are marked as OFFLINE are handled/finished/quiesced.
There are other folks on this thread who no doubt have more history/intimate knowledge of this driver than I do who may answer that question more quickly than I can…also, perhaps this discussion should probably be moved to the OFA driver forum since it has turned into a driver-specific thread at this point.
What do folks think?
Judy
From: 천원문 [mailto:wm.cheon at samsung.com]
Sent: Wednesday, April 17, 2013 1:20 AM
To: Judy Brock-SSI; 강미경; technical at nvmexpress.org<mailto:technical at nvmexpress.org>
Subject: Re: RE: Handling pending commands when processing Format

Hi Judy,

Would you elaborate more about  the "hot-remove" state? In this state, do you mean that all the IO SQ/CQs are deleted? Or, waiting for completions of all the outstanding IOs?

Thanks,
Wonmoon

------- Original Message -------
Sender : Judy Brock-SSI<judy.brock at ssi.samsung.com<mailto:judy.brock at ssi.samsung.com>>
Date : 2013-04-17 16:39 (GMT+09:00)
Title : RE: Handling pending commands when processing Format


Hi,
I should clarify that it is not the Windows operating system – but rather the Windows OFA  NVMe driver -  that, from what I can see,  does a “hot-remove” of all namespace(s) associated with a device before allowing a format operation to begin;  “hot remove” is just the name for an internal state in the driver format nvm state machine.
Before beginning the actual format op, the driver internally marks all  namespaces associated with the format operation “offline”. It then notifies the OS that there has been a “bus change” event (via an OS-specific API).
This in turn will cause the OS to rescan (re-enumerate) the “bus” (the pseudo SCSI bus, that is  –  we expose NVM namespaces as SCSI luns).
Since all the pertinent namespaces have been marked offline internally, the bus rescan won’t detect any valid SCSI luns (because the driver will not report any).
Hence from the OS point of view, any SCSI lun(s) previously mapped to the namespace(s) to be formatted will have disappeared/will be unaddressable while the format operation is in progress.
Judy

From: Judy Brock-SSI
Sent: Tuesday, April 16, 2013 8:22 PM
To: 'mkkang.kang at samsung.com'; technical at nvmexpress.org<mailto:technical at nvmexpress.org>
Subject: RE: Handling pending commands when processing Format

Mikyeong,
I haven’t looked at the Linux driver but I know that Windows hot-removes all namespace(s) associated with a device before allowing a format operation to begin. And a namespace can’t be removed while there is IO outstanding to it so that answers your question regarding IOs being completed before format begins. It also answers the question about requests being sent to a namespace while format is in progress – can’t happen.
Thanks,
Judy



From: 강미경 [mailto:mkkang.kang at samsung.com]
Sent: Tuesday, April 16, 2013 7:07 PM
To: technical at nvmexpress.org<mailto:technical at nvmexpress.org>
Subject: Handling pending commands when processing Format

Dear All,

Format NVM command may change the Namespace repository, and it will be executed out of order like any other commands. Therefore, Format NVM command may affect other commands that are pending execution in the device, if any.

1) How does an OFA/linux driver handle 'Format NVM command'? Does a host make sure that all commands for a particular NSID are completed before sending 'Format NVM command'?

2) If a host driver does not behave like 1) above, how can a device handle other pending commands which were previously submitted in a SQ? It seems like we need an additional status code. e.g. Abort due to Namespace Format

3) Let's suppose that 'Format NVM command' is in progress. If the host driver sends subsequent commands to the namespace being formatted, should the device reply directly with a 'Namespace not Ready'?

[1.0e spec] If the device does not reply directly and the format operation takes long time, then, I/O command will timeout and the host may send the reset. But if commands are responded with 'Namespace Not Ready', host may not issue the reset. Therefore, direct reply seems to be needed.

[1.1 spec. ECN 001] There is Format progress indicator. The host driver can check format progress any time, therefore, there is no concern about reset during format command.


Best Regards,
Mikyeong Kang

[X]
Kang MiKyeong


Flash Memory Planning/Enabling Group, Memory Div.
SAMSUNG ELECTRONICS, Co., Ltd..
Phone: 82-31-208-3857
Mobile: 82-10-9369-0177
E-mail: mkkang.kang at samsung.com<mailto:mkkang.kang at samsung.com>
[X]




[http://ext.samsung.net/mailcheck/SeenTimeChecker?do=dd90ab357fccaa0879ef49d135999623709a3a8db170c13642590acae5bdcb6a1b41a3ea5b94b2ed546e5f4bdee86ec72cb0372888719872db9fdddda33e82cbe4a391424e62fcf6cf878f9a26ce15a0]
[http://ext.samsung.net/mailcheck/SeenTimeChecker?do=dd90ab357fccaa0810067d8e81f72583c0a10306535965788c7e8eca81cb564b226b8d944a9d91d2f73afb615c53a27ef4bcdeced46ed5ee08cece8541bc14eacf878f9a26ce15a0]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20130418/267a4e1a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ATT87928 1.jpg
Type: image/jpeg
Size: 34869 bytes
Desc: ATT87928 1.jpg
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20130418/267a4e1a/attachment.jpg>