[PATCH v3 2/9] nvme-fabrics: allow to queue requests for live queues

[James Smart]

On 8/21/2020 12:44 PM, Sagi Grimberg wrote:
>
>>> I still dislike any random ioctls coming in while we're still 
>>> initializing
>>> the controller.
>>
>> Agreed.
>>
>>>    Looking at the flow - I wouldn't want them to be allowed
>>> until after nvme_init_identify() is complete. Especially if the 
>>> ioctls are
>>> doing subsystem or controller dumping or using commands that should be
>>> capped by values set by nvme_queue_limits().   But, if we're going to
>>> allow nvme_init_identify the admin_q needs to be unquiesced.
>>>
>>> So I'm still voting for the admin queue exception.
>>
>> And I really don't like the admin queue special case.  What is the
>> advantage of letting user space passthrough I/O commands in at this
>> point in time?
>
> We need to pass in normal I/O commands for sure in order to have a
> robust reset and error recovery (what in general the patchset
> addresses). What is the difference between FS I/O commands and
> passthru I/O commands? In fact, user passthru I/O commands will never
> execute before nvme_init_identify() because we always start
> the I/O queues after that.
>
> Let's look at pci, do we have the same enforcement for passthru
> commands? What's special about fabrics that we need to deny
> these commands from going through?

short answer - timing/latency and much much lower chance of failure.

I also don't think people are querying pci (local attached drivers) like 
they are fabric attachments.

-- james