[PATCH 2/3] nvme: enable uring-passthrough for admin commands

Kanchan Joshi joshiiitr at gmail.com
Tue May 17 06:50:52 PDT 2022


On Tue, May 17, 2022 at 1:45 PM Christoph Hellwig <hch at lst.de> wrote:
>
> On Tue, May 17, 2022 at 11:01:46AM +0530, Kanchan Joshi wrote:
> > Add a new opcode NVME_URING_CMD_ADMIN that userspace can use.
> > Wire up support for the case when this is issued over generic char
> > device node (/dev/ngXnY).
>
> I would really prefer not adding this to the per-namespaces nodes.
> The do something controller specific on the namespace node patter is
> a massive pain both in terms of code and semantics.

Both block (nvme0n1) and char (ng0n1) nodes allow admin-cmds to be
sent in the same way (with sync passthrough) as this patch does. So
same semantics when we support this for async/uring passthrough, IMHO.

To do passthrough read/write (and other stuff) via ns-generic
interface, uring-application will need information (such as lba
format) which can be obtained only with admin-commands. And if we
don't support what this patch does, it will have to either -

(a) get that information with sync-passthrough from /dev/ng0n1. Since
we clearly separated async-passthrough with separate opcode/struct, it
will need more bookkeeping to keep both sync and async dispatch
engines alive.

or

(b) maintain one more fd (for /dev/nvme0 node) and use that for async
dispatch whenever admin-cmd needs to be sent

Given the implications, is it not better to have this up on ns-char
node and applications get to use everything (io and admin cmds) in
async manner with async-specific opcode/struct only?

I will kill this if you still think it is a bad idea somehow, and move
the code of this to patch 3 (enable only /dev/nvme0). LMK.



More information about the Linux-nvme mailing list