nvme-fabrics: devices are uninterruptable

[Hannes Reinecke]

On 1/12/23 06:36, Kanchan Joshi wrote:
> On Wed, Jan 11, 2023 at 02:37:58PM +0000, Belanger, Martin wrote:
>> POSIX.1 specifies that certain functions such as read() or write() can 
>> act as cancellation points.
>>
>> Ref: 
>> https://pubs.opengroup.org/onlinepubs/000095399/functions/xsh_chap02_09.html#tag_02_09_05_02
> 
> Not exactly related to the original question, but I hear the
> cancellation requirement for passthrough too.
> 
> And it seems feasible as io_uring provides cancellation interface
> (IORING_OP_ASYNC_CANCEL) to user-space.
> It is only at io_uring level, and does not percolate down to lower
> layers (as we don't have an interface).
> Will it make sense to grow such interface for uring_cmd. Either
> a new file-op ->uring_cmd_cancel or existing ->uring_cmd with new
> cancel-flag. Not sure if ublk too needs it, but NVMe can support this 
> (new op/flag)
> cancellation by issuing abort-command to the device.
> 
> Down in nvme, we would need command-id/queue-id to issue abort command,
> and that maybe tricky to store (although it is something we do for
> iopoll). Maybe I can figure something out while cooking up a RFC.
> 
> But first things first, Christoph, Jens: does this sound reasonable?
> 
Command aborts for io_uring! Yay!

Something I have been needing for since ages immemorial; KVM suffers 
from this as we can't do a command abort from the guest.
Meaning we always will have to wait for command completion _from the 
host_, making it impossible to trigger a failover or even start error 
recovery.

So, yes, please. We should at least look at it, and io_uring looks 
ideally suited.

Cheers,

Hannes