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

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

On 2/24/26 22:19, Joanne Koong wrote:
> On Mon, Feb 23, 2026 at 12:00 PM Pavel Begunkov <asml.silence@gmail.com> wrote:
>>
>> On 2/21/26 02:14, Joanne Koong wrote:
>>> On Fri, Feb 20, 2026 at 4:53 AM Pavel Begunkov <asml.silence@gmail.com> wrote:
>> ...
>>>> So I'm asking whether you expect that a server or other user space
>>>> program should be able to issue a READ_OP_RECV, READ_OP_READ or any
>>>> other similar request, which would consume buffers/entries from the
>>>> km ring without any fuse kernel code involved? Do you have some
>>>> use case for that in mind?
>>>
>>> Thanks for clarifying your question. Yes, this would be a useful
>>> optimization in the future for fuse servers with certain workload
>>> characteristics (eg network-backed servers with high concurrency and
>>> unpredictable latencies). I don't think the concept of kmbufrings is
>>> exclusively fuse-specific though (for example, Christoph's use case
>>> being a recent instance);
>>
>> Sorry, I don't see relevance b/w km rings and what Christoph wants.
>> I explained why in some sub-thread, but maybe someone can tell
>> what I'm missing.
>>
>>> I think other subsystems/users that'll use
>>> kmbuf rings would also generically find it useful to have the option
>>> of READ_OP_RECV/READ_OP_READ operating directly on the ring.
>>
>> Yep, it could be, potentially, it's just the patchset doesn't plumb
>> it to other requests and uses it within fuse. It's just cases like
> 
> This patchset just represents the most basic foundation. The
> optimization patches (eg incremental buffer consumption, plumbing it
> to other io-uring requests, etc) were to be follow-up patchsets that
> would be on top of this.

Got it. Any understanding how the work flow would look like if used
with non-cmd io_uring requests? Is there some particular use case
you have in mind for fuse servers?

>> that always make me wonder, here it was why what is basically an
>> internal kernel fuse API is exposed as an io_uring uapi. Maybe there
> 
> It's not really an internal kernel fuse API. There's nothing
> fuse-specific about it - the infrastructure that's added is the
> infrastructure for a generic buffer ring.
> 
> The memory that backs the buffers for the buf ring needs to be
> io-uring specific. io-uring already has all the infrastructure for
> buffer rings. So I'm not really fully understanding why it's better in
> this case to just have the fuse kernel code re-implement all the logic
> for a buffer ring and go through these layers of indirection to use
> registered buffers, instead of just leveraging what's already in
> io-uring.

It's simple. If user space (i.e. fuse server) knows the buffer
address prior to request submission, then it should either use plain
user addresses or registered buffers. Introducing a major io_uring
uapi extension that does the same thing as registered buffers but
for regions, as you suggested, is not the right approach.

...
>> It's up to the user (i.e. fuse server) to either use OP_READ/etc. using
>> user addresses that you have in your design from mmap()ing regions, or
>> registering it and using OP_READ_FIXED.
> 
> Yes but I don't think this solves the concern of userspace being able
> to unregister the memory region at any time (eg while not doing
> io-uring requests) while the kernel still points to those addresses
> for the backing buffers of the bufring, since there's no callback that

If you allow normal requests to use it, a fuse callback on region
unregistration wouldn't help anyway.

> gets triggered in the subsystem when a memory region is unregistered,
> which means there will need to be extra per I/O overhead for having to
> ensure the memory region is still valid. Though since there's no uapi
> for unregistering a memory region this is not a concern, unless this
> is planned to be added in the future.

You can assume it's not going to be unregistered.

-- 
Pavel Begunkov