Re: [RFC v1 3/3] io_uring: introduce io_uring querying

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

On 8/27/25 19:04, Gabriel Krisman Bertazi wrote:
> Pavel Begunkov <asml.silence@gmail.com> writes:
> 
>> There are many characteristics of a ring or the io_uring subsystem the
>> user wants to query. Sometimes it's needed to be done before there is a
>> created ring, and sometimes it's needed at runtime in a slow path.
>> Introduce a querying interface to achieve that.
>>
>> It was written with several requirements in mind:
>> - Can be used with or without an io_uring instance.
>> - Can query multiple attributes in one syscall.
>> - Backward and forward compatible.
>> - Should be reasobably easy to use.
>> - Reduce the kernel code size for introducing new query types.
> 
> Hello, Pavel.
> 
> Correct me if I'm wrong, or if I completely missed the point, but this
> is mostly about returning static information about what the kernel

It's primarily about configuring rings from within the application
at different steps, and it's always a huge mess when that requires
reading and parsing a text file. It's not all static either, my
main agenda here (not included) involves calculations.

> supports, which can all be calculated at compile-time.
I assume you mean kernel compilation, I can't rely on app
recompilation every time kernel changes.

> It seems it should be laid out as a procfs/sysfs /sys/kernel/io_uring
> subtree instead, making it quickly parseable with the usual coreutils
> command line tools, and then abstracted by some liburing APIs.  I don't
> see the advantage of creating a custom way for fetching kernel features
> information that only works for io_uring.
> 
> Sure, parsing sysfs is slow, but it doesn't need to be fast.  It is
> annoying, but it can be abstracted in userspace by liburing.  It is more

FWIW, I see usefulness in it not being painstakingly slow as it
might easily become with files. E.g. it can be reused to return
stats the app needs at runtime.

Funnily, it'd would create a dependency where you can't create
a ring without having another downgraded ring or using read/write
etc. syscall.

And that also won't work with fd-less ring, aka
IORING_SETUP_REGISTERED_FD_ONLY. Not sure why those are a thing,
but it wouldn't hurt to support it.

> consistent with the rest of the kernel and, for me, when tracking
> customer issues, I can trust the newly introduce files will show up in
> their supportconfig/sosreport without any extra change to these
> applications.
> 
> Then there is the part about probing a specific ring for something, and
> we have fdinfo. What information do we want to probe of a
> particular ring that is missing?  Perhaps this feature should be split from the
> general "is this feature supported" part.

The existing io_uring fdinfo is a huge mess. The format is not
great and it prints too much garbage, parsing it will be a misery.
It's not better implementation wise either, evident by the amount
of bugs it had and reversed lock nesting with trylocks.

And some queries are going to be parameterised, and there is no
good way to pass that to a file read.

-- 
Pavel Begunkov