[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z-bc3Hjc2eVSRK7X@kbusch-mbp.dhcp.thefacebook.com>
Date: Fri, 28 Mar 2025 11:31:08 -0600
From: Keith Busch <kbusch@...nel.org>
To: Caleb Sander Mateos <csander@...estorage.com>
Cc: Jens Axboe <axboe@...nel.dk>, Christoph Hellwig <hch@....de>,
Sagi Grimberg <sagi@...mberg.me>,
Pavel Begunkov <asml.silence@...il.com>,
Chaitanya Kulkarni <kch@...dia.com>, linux-nvme@...ts.infradead.org,
io-uring@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 0/3] nvme_map_user_request() cleanup
On Fri, Mar 28, 2025 at 09:46:44AM -0600, Caleb Sander Mateos wrote:
> The first commit removes a WARN_ON_ONCE() checking userspace values.
> The last 2 move code out of nvme_map_user_request() that belongs better
> in its callers, and move the fixed buffer import before going async.
> As discussed in [1], this allows an NVMe passthru operation submitted at
> the same time as a ublk zero-copy buffer unregister operation to succeed
> even if the initial issue goes async. This can improve performance of
> userspace applications submitting the operations together like this with
> a slow fallback path on failure. This is an alternate approach to [2],
> which moved the fixed buffer import to the io_uring layer.
Thanks, applied to nvme for-next. I'll replay this to nvme-6.15 after
block-6.15 rebases to Linus master.
> There will likely be conflicts with the parameter cleanup series Keith
> posted last month in [3].
No worries, this actually makes some of those cleanups eaiser.
Powered by blists - more mailing lists