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

[Bart Van Assche <bvanassche@acm.org>]

On 2/8/21 7:12 PM, Keith Busch wrote:
> On Tue, Feb 09, 2021 at 12:53:17AM +0000, Clay Mayers wrote:
>> 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?
> 
> The complications it introduces to the IO path and error handling for an
> archaic feature has me on the "Nak" side. NVMeOF was introduced well after the
> spec define Reservations, and the kernel has supported that capability for many
> years. I'm not aware of any other use case for fused commands, so it appears to
> be dead weight in the spec.

Hi Keith,

Do you agree that NVMe persistent reservation commands apply to an NVMe 
namespace in its entirety while fused compare-and-write commands allow 
to implement locking for subsets of the LBA range of a namespace? In 
other words, I think there is a valid use case for fused commands.

Thanks,

Bart.

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme