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

[Joanne Koong <joannelkoong@gmail.com>]

On Fri, Feb 13, 2026 at 4:41 AM Pavel Begunkov <asml.silence@gmail.com> wrote:
>
> On 2/13/26 07:18, Christoph Hellwig wrote:
> > On Thu, Feb 12, 2026 at 10:44:44AM +0000, Pavel Begunkov wrote:
> >>>
> > Can you clarify what you mean with 'pbuf'?  The only fixed buffer API I
> > know is io_uring_register_buffers* which always takes user provided
> > buffers, so I have a hard time parsing what you're saying there.  But
> > that might just be sign that I'm no expert in io_uring APIs, and that
> > web searches have degraded to the point of not being very useful
> > anymore.
>
> Registered, aka fixed, buffers are the ones you pass to
> IORING_OP_[READ,WRITE]_FIXED and some other requests. It's normally
> created by io_uring_register_buffers*() / IORING_REGISTER_BUFFERS*
> with user memory, but there are special cases when it's installed
> internally by other kernel components, e.g. ublk.
> This series has nothing to do with them, and relevant parts of
> the discussion here don't mention them either.
>
> Provided buffer rings, a.k.a pbuf rings, IORING_REGISTER_PBUF_RING
> is a kernel-user shared ring. The entries are user buffers
> {uaddr, size}. The user space adds entries, the kernel (io_uring
> requests) consumes them and issues I/O using the user addresses.
> E.g. you can issue a IORING_OP_RECV request (+IOSQE_BUFFER_SELECT)
> and it'll grab a buffer from the ring instead of using sqe->addr.
>
> pbuf rings, IORING_REGISTER_MEM_REGION, completion/submission
> queues and all other kernel-user rings/etc. are internally based
> on so called regions. All of them support both user allocated
> memory and kernel allocations + mmap.
>
> This series essentially creates provided buffer rings, where
> 1. the ring now contains kernel addresses
> 2. the ring itself is in-kernel only and not shared with user space
> 3. it also allocates kernel buffers (as a region), populates the ring
>     with them, and allows mapping the buffers into the user space.

The most important part and the whole reason fuse needs the buffer
ring to be kernel-managed is because the kernel needs to control when
buffers get recycled back into the ring. For fuse's use case, the
buffer is used for passing data between the kernel and the server. We
can't have the server recycle the buffer because the server writes
back data to the kernel in that buffer when it submits the sqe. After
fuse receives the sqe and reads the reply from the server, it then
needs to recycle that buffer back into the ring so it can be reused
for a future cqe (eg sending a future request).

>
> Fuse is doing both adding (kernel) buffers to the ring and consuming
> them. At which point it's not clear:
>
> 1. Why it even needs io_uring provided buffer rings, it can be all
>     contained in fuse. Maybe it's trying to reuse pbuf ring code as
>     basically an internal memory allocator, but then why expose buffer
>     rings as an io_uring uapi instead of keeping it internally.
>
>     That's also why I mentioned whether those buffers are supposed to
>     be used with other types of io_uring requests like recv, etc.

On the userspace/server side, it uses the buffers for other io-uring
operations (eg reading or writing the contents from/to a
locally-backed file).

>
> 2. Why making io_uring to allocate payload memory. The answer to which
>     is probably to reuse the region api with mmap and so on. And why
>     payload buffers are inseparably created together with the ring

My main motivation for this is simplicity. I see (and thanks for
explaining) that using a registered mem region allows the use of some
optimizations (the only one I know of right now is the PMD one you
mentioned but maybe there's more I'm missing) that could be useful for
some workloads, but I don't think (and this could just be my lack of
understanding of what more optimizations there are) most use cases of
kmbufs benefit from those optimizations, so to me it feels like we're
adding non-trivial complexity for no noticeable benefit.

I feel like we get the best of both worlds by letting users have both:
the simple kernel-managed pbuf where the kernel allocates the buffers
and the buffers are tied to the lifecycle of the ring, and the more
advanced kernel-managed pbuf where buffers are tied to a registered
memory region that the subsystem is responsible for later populating
the ring with.

>     and via a new io_uring uapi.

imo it felt cleaner to have a new uapi for it because kmbufs and pbufs
have different expectations and behaviors (eg pbufs only work with
user-provided buffers and requires userspace to populate the ring
before using it, whereas for kmbufs the kernel allocates the buffers
and populates it for you; pbufs require userspace to recycle back the
buffer, whereas for kmbufs the kernel is the one in control of
recycling) and from the user pov it seemed confusing to have kmbufs as
part of the pbuf ring uapi, instead of separating it out as a
different type of ringbuffer with a different expectation and
behavior. I was trying to make the point that combining the interface
if we go with IORING_MEM_REGION gets even more confusing because now
pbufs that are kernel-managed are also empty at initialization and
only can point to areas inside a registered mem region and the
responsibility of populating it is now on whatever subsystem is using
it.

I still have this opinion but I also think in general, you likely know
better than I do what kind of io-uring uapi is best for io-uring's
users. For v2 I'll have kmbufs go through the pbuf uapi.

>
>     And yes, I believe in the current form it's inflexible, it requires
>     a new io_uring uapi. It requires the number of buffers to match
>     the number of ring entries, which are related but not the same

I'm not really seeing what the purpose of having a ring entry with no
buffer associated with it is. In the existing code for non-kernel
managed pbuf rings, there's the same tie between reg->ring_entries
being used as the marker for how many buffers the ring supports. But
if the number of buffers should be different than the number of ring
entries, this can be easily fixed by passing in the number of buffers
from the uapi for kernel-managed pbuf rings.

>     thing. You can't easily add more memory as it's bound to the ring
>     object. The buffer memory won't even have same lifetime as the

To play devil's advocate, we also can't easily add more memory to the
mem region once it's been registered. I think there's also a worse
penalty where the user needs to know upfront how much memory to
allocate for the mem region for the lifetime of the ring, which imo
may be hard to do (eg if a kernel-managed buf ring only needs to be
registered for some code paths and not others, the mem region
registration would still have to allocate the memory a potential kbuf
ring would use).

>     ring object -- allow using that km buffer ring with recv requests
>     and highly likely I'll most likely give you a way to crash the
>     kernel.

I'm a bit confused by this part. The buffer memory does have the same
lifetime as the ring object, no? The buffers only get freed when the
ring itself is freed.

>
> But hey, I'm tired. I don't have any beef here and am only trying
> to make it a bit cleaner and flexible for fuse in the first place
> without even questioning the I/O path. If everyone believes

I appreciate you looking at this and giving your feedback and insight.
Thank you for doing so. I don't want to merge in something you're
unhappy with.

Are you open to having support for both a simple kernel-managed pbuf
interface and later on if/when the need arises, a kernel-managed pbuf
interface that goes through a registered memory region? If the answer
is no, then I'll make the change to have kmbufs go through the
registered memory region.

Thanks,
Joanne

> everything is right, just ask Jens to merge it.
>
> --
> Pavel Begunkov
>