Re: [PATCH v1 03/11] io_uring/kbuf: add support for kernel-managed buffer rings

[Pavel Begunkov <asml.silence@gmail.com>]

On 2/17/26 05:38, Christoph Hellwig wrote:
> On Fri, Feb 13, 2026 at 11:14:03AM -0800, Joanne Koong wrote:
>> I think we have the exact same use case, except your buffers need to
>> be read-only. I think your use case benefits from the same memory wins
>> we'll get with incremental buffer consumption, which is the primary
>> reason fuse is using a bufring instead of fixed buffers.
> 
> Yeah.

Provided buffer rings are not useful for storage read/write requests
because they bind to a buffer right away, that's in contrast to some
recv request, where io_uring will first poll the socket to confirm
the data is there, and only then take a buffer from the buffer ring
and copy into it. With storage rw it makes more sense to specify
the buffer directly gain control over where exactly data lands
IOW, instead of the usual "read data into a given pointer" request
semantics like what read(2) gives you, buffer rings are rather
"read data somewhere and return a pointer to where you placed it".

Another problem is that someone needs to return buffers back into
the buffer ring, and it's a kernel private ring. For this patchset
it's assumed the fuse driver is going to be doing that, but there
is no one for normal rw requests.

>> I think you can and it'll be very easy to do so. All that would be
>> needed is to pass in a read-only flag from the userspace side when it
>> registers the bufring, and then when userspace makes the mmap call to
>> the bufring, the kernel checks if that read-only flag is set on the
>> bufring and if so returns a read-only mapping.
> 
> Yes, tat's what I though.  But Pavel seems to disagree?

Yes. You only need buffers, and it'll be better to base on sth that
gives you buffers/memory without extra semantics, i.e.
IORING_MEM_REGION. Or it can be a standalone registered buffer
extension, likely reusing regions internally. That might even yield
a finer API.

-- 
Pavel Begunkov