Re: [PATCH v2 1/8] io_uring/uring_cmd: add io_uring_cmd_import_fixed_full()

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

On 10/29/25 19:59, Bernd Schubert wrote:
> On 10/29/25 19:37, Joanne Koong wrote:
>> On Wed, Oct 29, 2025 at 7:01 AM Pavel Begunkov <asml.silence@gmail.com> wrote:
>>>
>>> On 10/27/25 22:28, Joanne Koong wrote:
>>>> Add an API for fetching the registered buffer associated with a
>>>> io_uring cmd. This is useful for callers who need access to the buffer
>>>> but do not have prior knowledge of the buffer's user address or length.
>>>
>>> Joanne, is it needed because you don't want to pass {offset,size}
>>> via fuse uapi? It's often more convenient to allocate and register
>>> one large buffer and let requests to use subchunks. Shouldn't be
>>> different for performance, but e.g. if you try to overlay it onto
>>> huge pages it'll be severely overaccounted.
>>>
>>
>> Hi Pavel,
>>
>> Yes, I was thinking this would be a simpler interface than the
>> userspace caller having to pass in the uaddr and size on every
>> request. Right now the way it is structured is that userspace
>> allocates a buffer per request, then registers all those buffers. On
>> the kernel side when it fetches the buffer, it'll always fetch the
>> whole buffer (eg offset is 0 and size is the full size).
>>
>> Do you think it is better to allocate one large buffer and have the
>> requests use subchunks? My worry with this is that it would lead to
>> suboptimal cache locality when servers offload handling requests to
>> separate thread workers. From a code perspective it seems a bit
>> simpler to have each request have its own buffer, but it wouldn't be
>> much more complicated to have it all be part of one large buffer.
> 
> I don't think it would be a huge issue to let userspace allocate a large
> buffer and to distribute it among requests - there is nothing in the
> kernel side to be done for that?

You can, but unless I missed something with this patchset you'd need
to register it N times, which is not terrible but have memory
overaccounting problems and feels less flexible.

> (I think I had even done that for the 1st io-uring patches and removed
> it because there were other issues and I wanted to keep the initial code
> simple).

-- 
Pavel Begunkov