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

From: Jens Axboe <axboe@kernel.dk>
To: Christoph Hellwig <hch@lst.de>, Kanchan Joshi <joshiiitr@gmail.com>
Cc: "Kanchan Joshi" <joshi.k@samsung.com>,
	io-uring@vger.kernel.org, linux-nvme@lists.infradead.org,
	"Pavel Begunkov" <asml.silence@gmail.com>,
	"Ming Lei" <ming.lei@redhat.com>,
	"Luis Chamberlain" <mcgrof@kernel.org>,
	"Pankaj Raghav" <pankydev8@gmail.com>,
	"Javier González" <javier@javigon.com>,
	"Anuj Gupta" <anuj20.g@samsung.com>
Subject: Re: [RFC 5/5] nvme: wire-up support for async-passthru on char-device.
Date: Tue, 5 Apr 2022 09:40:49 -0600	[thread overview]
Message-ID: <51171191-943f-b9e4-b78b-674834de00b1@kernel.dk> (raw)
In-Reply-To: <20220405060224.GE23698@lst.de>

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