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
