Re: [PATCH io_uring-7.1 v5 0/5] BPF controlled io_uring

[Jens Axboe <axboe@kernel.dk>]

On 2/11/26 7:32 AM, Pavel Begunkov wrote:
> This series introduces a way to override the standard io_uring_enter
> syscall execution with an extendible event loop, which can be controlled
> by BPF via new io_uring struct_ops or from within the kernel.
> 
> There are multiple use cases I want to cover with this:
> 
> - Syscall avoidance. Instead of returning to the userspace for
>   CQE processing, a part of the logic can be moved into BPF to
>   avoid excessive number of syscalls.
> 
> - Access to in-kernel io_uring resources. For example, there are
>   registered buffers that can't be directly accessed by the userspace,
>   however we can give BPF the ability to peek at them. It can be used
>   to take a look at in-buffer app level headers to decide what to do
>   with data next and issuing IO using it.
> 
> - Smarter request ordering and linking. Request links are pretty
>   limited and inflexible as they can't pass information from one
>   request to another. With BPF we can peek at CQEs and memory and
>   compile a subsequent request.
> 
> - Feature semi-deprecation. It can be used to simplify handling
>   of deprecated features by moving it into the callback out core
>   io_uring. For example, it should be trivial to simulate
>   IOSQE_IO_DRAIN. Another target could be request linking logic.
> 
> - It can serve as a base for custom algorithms and fine tuning.
>   Often, it'd be impractical to introduce a generic feature because
>   it's either niche or requires a lot of configuration. For example,
>   there is support min-wait, however BPF can help to further fine tune
>   it by doing it in multiple steps with different number of CQEs /
>   timeouts. Another feature people were asking about is allowing
>   to over queue SQEs but make the kernel to maintain a given QD.
> 
> - Smarter polling. Napi polling is performed only once per syscall
>   and then it switches to waiting. We can do smarter and intermix
>   polling with waiting using the hook.
> 
> It might need more specialised kfuncs in the future, but the core
> functionality is implemented with just two simple functions. One
> returns region memory, which gives BPF access to CQ/SQ/etc. And
> the second is for submitting requests. It's also given a structure
> as an argument, which is used to pass waiting parameters.
> 
> It showed good numbers in a test that sequentially executes N nop
> requests, where BPF was more than twice as fast than a 2-nop
> request link implementation.
> 
> I've got ideas on how the user space part while writing toy programs,
> mostly about simplifying life to BPF writers, but I want to turn it
> into something more cohesive before posting.

This looks nifty. Do you have a repo on the liburing side with some
examples to play with?

Nit on some of the new files added, not all of them have SPDX headers.

-- 
Jens Axboe