[PATCH V2 0/2] nvme: Support for fused NVME_IOCTL_SUBMIT_IO

[Clay Mayers]

> From: Clay Mayers
> Sent: Tuesday, January 26, 2021 1:14 PM
> To: linux-nvme at lists.infradead.org
> Cc: Keith Busch <kbusch at kernel.org>; Jens Axboe <axboe at fb.com>;
> 'Chaitanya Kulkarni' <Chaitanya.Kulkarni at wdc.com>;
> Christoph Hellwig <hch at lst.de>; Sagi Grimberg <sagi at grimberg.me>
> Subject: RE: [PATCH V2 0/2] nvme: Support for fused
> NVME_IOCTL_SUBMIT_IO
>
Is there any other feedback on V2?

My main concern I have about my implementation is how fused requests
are tunneled through the mq request layer.  The 1st request is marked as
started but it won't be in the device until the 2nd command is queued.  As
Keith pointed out, a device reset can split the two so care must be taken to
correctly handle this case.  Despite this, I thought this was a better approach
than modifying mq requests to be fused.  Especially given Christoph's 
concern of cost vs value.  This is the lightest touch I could come up with.

Further consideration of this patch may need a more compelling use case.
I've worked on a proprietary storage systems that relied on fused NVMeOF
support so it seems compelling to me.  There's a comment in target/core.c
that there is "no support for fused commands yet" implying it's been
considered.  Is pci only support for fused too soon or too little?  What would
make it more compelling?