Re: [PATCH 7/7] nvme: allow send fused commands

[Dmitry Bogdanov <d.bogdanov@yadro.com>]

Hi,

> There is prior discussion about exactly this change at
> https://github.com/linux-nvme/nvme-cli/issues/318. The concerns raised
> there still appear valid 6 years later. The main issue is that this
> interface requires 2 separate ioctls/io_uring operations to submit a
> Fused Compare and Write. That means the 2 commands could be submitted
> to different I/O queues, which wouldn't work. Not to mention that 2
> threads are required in order to submit the commands concurrently if
> the blocking ioctls are used. Additionally, another application using
> the NVMe controller concurrently could submit a command in between the
> fused commands, which would also break the Fused Compare and Write.

This patch is not for a production usage of Fused commands from the host,
but instead it is just for the purpose to test the target side. Of course,
it has some limitations like working only with one IO queue and one
user, but all of that is under the user's control:

# nvme connect-all -i 1 -t tcp 
# nvme io-passthru --o 0x5 -n 1 -f 0x1 -w --cdw10=0 --cdw12=0x0 -l 4096 -i ./4k0 /dev/nvme0n1 & nvme io-passthru --o 0x1 -n 1 -f 0x2 -w --cdw10=0 --cdw12=0x0 -l 4096 -i ./4k1 /dev/nvme0n1
NVMe command result:00000000
NVMe command result:00000000

And the patch provides enough kernel functionality to test the target side.

> 
> FYI there was a set of patches sent to the mailing list
> https://lore.kernel.org/linux-nvme/20210105224939.1336-1-clay.mayers@kioxia.com/T/#u
> that attempted to implement a new passthru ioctl for submitting fused
> commands. But it adds memory overhead to each NVMe request and there
> are a lot of corner cases to consider around error handling.
> 
> As an implementer of Fused Compare and Write on the target side, I can
> say the concept of "fused commands" is pretty horrible to work with.
> It breaks the model where each NVMe command is an independent
> operation and requires a ton of additional error propagation logic.
> Not to mention that the NSID, SLBA, and NLB parameters are now
> duplicated between the 2 commands... As far as I can tell, the only
> reason to make the operation 2 commands is to allow a separate PRP/SGL
> for each command. I guess this avoids the memcpy that would be
> required if a single concatenated data buffer was used? But at what
> cost???
> 
> On Wed, Sep 11, 2024 at 11:45 PM Dmitry Bogdanov <d.bogdanov@yadro.com> wrote:
> >
> > Allow a user to pass fused flags for the commands.
> >
> > Signed-off-by: Dmitry Bogdanov <d.bogdanov@yadro.com>