Re: nvme-fabrics: devices are uninterruptable

[Kanchan Joshi <joshi.k@samsung.com>]

[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]

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?

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]