On Mon, Jul 11, 2022 at 12:24:42PM -0600, Jens Axboe wrote:
On 7/11/22 12:22 PM, Sagi Grimberg wrote:
Use the leftover space to carve 'next' field that enables linking of
io_uring_cmd structs. Also introduce a list head and few helpers.
This is in preparation to support nvme-mulitpath, allowing multiple
uring passthrough commands to be queued.
It's not clear to me why we need linking at that level?
I think the attempt is to allow something like blk_steal_bios that
nvme leverages for io_uring_cmd(s).
I'll rephrase because now that I read it, I think my phrasing is
confusing.
I think the attempt is to allow something like blk_steal_bios that
nvme leverages, but for io_uring_cmd(s). Essentially allow io_uring_cmd
to be linked in a requeue_list.
I see. I wonder if there's some other way we can accomplish that, so we
don't have to shrink the current space. io_kiocb already support
linking, so seems like that should be workable.
nvme failover steals all the bios from requests that fail (and should
failover) and puts them on a requeue list, and then schedules
a work that takes these bios one-by-one and submits them on a different
bottom namespace (see nvme_failover_req/nvme_requeue_work).
Maybe if io_kiocb could exposed to nvme, and it had some generic space
that nvme could use, that would work as well...
It will be more exposed in 5.20, but passthrough is already using the
per-op allotted space in the io_kiocb. But as mentioned above, there's
already linking support between io_kiocbs, and that is likely what
should be used here too.
io_kiocb linking is used if user-space wants to link SQEs for any
ordering. If we go this route, we give up that feature for
uring-command SQEs.
