[RFC 5/5] nvme: wire-up support for async-passthru on char-device.

[Jens Axboe]

On 4/5/22 12:02 AM, Christoph Hellwig wrote:
> On Mon, Apr 04, 2022 at 07:55:05PM +0530, Kanchan Joshi wrote:
>>> Something like this (untested) patch should help to separate
>>> the much better:
>>
>> It does, thanks. But the only thing is - it would be good to support
>> vectored-passthru too (i.e. NVME_IOCTL_IO64_CMD_VEC) for this path.
>> For the new opcode "NVME_URING_CMD_IO" , either we can change the
>> cmd-structure or flag-based handling so that vectored-io is supported.
>> Or we introduce NVME_URING_CMD_IO_VEC also for that.
>> Which one do you prefer?
> 
> I agree vectored I/O support is useful.
> 
> Do we even need to support the non-vectored case?

I would argue that 99% of the use cases will be non-vectored,
and non-vectored is a lot cheaper to handle for deferrals as
there's no iovec to keep persistent on the io_uring side. So
yes, I'd say we _definitely_ want to have non-vectored be
available and the default thing that applications use unless
they explicitly want more than 1 segment in a request.

-- 
Jens Axboe