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

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

On 2/12/26 17:29, Joanne Koong wrote:
> On Thu, Feb 12, 2026 at 2:52 AM Pavel Begunkov <asml.silence@gmail.com> wrote:
>>
>> On 2/12/26 10:07, Christoph Hellwig wrote:
>>> On Wed, Feb 11, 2026 at 02:06:18PM -0800, Joanne Koong wrote:
>>>>> I don't think I follow. I'm saying that it might be interesting
>>>>> to separate rings from how and with what they're populated on the
>>>>> kernel API level, but the fuse kernel module can do the population
>>>>
>>>> Oh okay, from your first message I (and I think christoph too) thought
>>>> what you were saying is that the user should be responsible for
>>>> allocating the buffers with complete ownership over them, and then
>>>> just pass those allocated to the kernel to use. But what you're saying
>>>> is that just use a different way for getting the kernel to allocate
>>>> the buffers (eg through the IORING_REGISTER_MEM_REGION interface). Am
>>>> I reading this correctly?
>>>
>>> I'm arguing exactly against this.  For my use case I need a setup
>>> where the kernel controls the allocation fully and guarantees user
>>> processes can only read the memory but never write to it.  I'd love
> 
> By "control the allocation fully" do you mean for your use case, the
> allocation/setup isn't triggered by userspace but is initiated by the
> kernel (eg user never explicitly registers any kbuf ring, the kernel
> just uses the kbuf ring data structure internally and users can read
> the buffer contents)? If userspace initiates the setup of the kbuf
> ring, going through IORING_REGISTER_MEM_REGION would be semantically
> the same, except the buffer allocation by the kernel now happens
> before the ring is created and then later populated into the ring.
> userspace would still need to make an mmap call to the region and the
> kernel could enforce that as read-only. But if userspace doesn't
> initiate the setup, then going through IORING_REGISTER_MEM_REGION gets
> uglier.
> 
>>> to be able to piggy back than onto your work.
>>
>> IORING_REGISTER_MEM_REGION supports both types of allocations. It can
>> have a new registration flag for read-only, and then you either make
>> the bounce avoidance optional or reject binding fuse to unsupported
>> setups during init. Any arguments against that? I need to go over
>> Joanne's reply, but I don't see any contradiction in principal with
>> your use case.
> 
> So i guess the flow would have to be:
> a) user calls io_uring_register_region(&ring, &mem_region_reg) with
> mem_region_reg.region_uptr's size field set to the total buffer size
> (and mem_region_reg.flags read-only bit set if needed)
>       kernel allocates region
> b) user calls mmap() to get the address of the region. If read-only
> bit was set, it gets a read-only address
> c) user calls io_uring_register_buf_ring(&ring, &buf_reg, flags) with
> buf_reg.flags |= IOU_PBUF_RING_KERNEL_MANAGED
>       kernel creates an empty kernel-managed ring. None of the buffers
> are populated
> d) user tells X subsystem to populate the ring starting from offset Z
> in the registered mem region
> e) on the kernel side, the subsystem populates the ring starting from
> offset Z, filling it up using the buf_size and ring_entries values
> that the user registered the ring with in c)
> 
> To be completely honest, the more I look at this the more this feels
> like overkill / over-engineered to me. I get that now the user can do
> the PMD optimization, but does that actually lead to noticeable
> performance benefits? It seems especially confusing with them going

No, it's mainly about not keeping payload buffers and rings in the same
object from the io_uring uapi perspective.

1. If it's an io_uring uapi, it shouldn't be fuse specific or with
a bunch of use case specific expectations attached. Why does it
require all buffers to be uniform in size? Why does it require
the ring size to match the number of buffers? Why does it require
buffers to be allocated by io_uring in the first place? Maybe some
subsystem got memory from somewhere else and wants to do use it
with io_uring. Why does it need to know the total size at creation,
and what would you do if you want to add more memory at runtime
while using the same ring?

2. If it's meant to be fuse specific and _not_ used with other requests
like recv/read/etc., then what's the point of having it as an io_uring
uapi? Which also adds additional trouble like the once you're solving
with pinning.

If it's supposed to be used with other requests, then buffers and
rings will have different in-kernel lifetime expectations imposed
by io_uring, so having them together won't even help with
management.

I have a strong opinion about the memmap.c change. For the
rest, if you believe it's fine, just send it out and let Jens
decide.

> through the same pbuf ring interface but having totally different
> expectations.

It's predicated on separating buffers from rings, see above,
and assuming that I'm not sure what expectations are different
apart from one being in-kernel with kernel addresses and the
other user visible with user addresses.

-- 
Pavel Begunkov