Re: [PATCH 0/5] io_uring: add IORING_OP_BPF for extending io_uring

[Ming Lei <ming.lei@redhat.com>]

On Wed, Nov 05, 2025 at 12:47:58PM +0000, Pavel Begunkov wrote:
> On 11/4/25 16:21, Ming Lei wrote:
> > Hello,
> > 
> > Add IORING_OP_BPF for extending io_uring operations, follows typical cases:
> 
> BPF requests were tried long time ago and it wasn't great. Performance

Care to share the link so I can learn from the lesson? Maybe things have
changed now...

> for short BPF programs is not great because of io_uring request handling
> overhead. And flexibility was severely lacking, so even simple use cases

What is the overhead? In this patch, OP's prep() and issue() are defined in
bpf prog, but in typical use case, the code size is pretty small, and bpf
prog code is supposed to run in fast path.

> were looking pretty ugly, internally, and for BPF writers as well.

I am not sure what `simple use cases` you are talking about.

> 
> I'm not so sure about your criteria, but my requirement was to at least
> being able to reuse all io_uring IO handling, i.e. submitting requests,
> and to wait/process completions, otherwise a lot of opportunities are
> wasted. My approach from a few months back [1] controlling requests from

Please read the patchset.

This patchset defines new IORING_BPF_OP code, which's ->prep(), ->issue(), ...,
are hooked with struct_ops prog, so all io_uring core code is used, just the
exact IORING_BPF_OP behavior is defined by struct_ops prog.

> the outside was looking much better. At least it covered a bunch of needs
> without extra changes. I was just wiring up io_uring changes I wanted
> to make BPF writer lifes easier. Let me resend the bpf series with it.
> 
> It makes me wonder if they are complementary, but I'm not sure what

I think the two are orthogonal in function, and they can co-exist.

> your use cases are and what capabilities it might need.

The main use cases are described in cover letter and the 3rd patch, please
find the details there.

So far the main case is to access the registered (kernel)buffer
from issue() callback of struct_ops, because the buffer doesn't have
userspace mapping. The last two patches adds support to provide two
buffers(fixed, plain) for IORING_BPF_OP, and in future vectored buffer
will be added too, so IORING_BPF_OP can handle buffer flexibly, such as:

- use exported compress kfunc to compress data from kernel buffer
into another buffer or inplace, then the following linked SQE can be submitted
to write the built compressed data into storage

- in raid use case, calculate IO data parity from kernel buffer, and store
the parity data to another plain user buffer, then the following linked SQE
can be submitted to write the built parity data to storage

Even for userspace buffer, the BPF_OP can support similar handling for saving
one extra io_uring_enter() syscall.

> 
> [1] https://lore.kernel.org/io-uring/cover.1749214572.git.asml.silence@gmail.com/

I looked at your patches, in which SQE is generated in bpf prog(kernel),
and it can't be used in my case.


Thanks,
Ming