Re: [PATCH v8 5/5] selftests/io_uring: add a bpf io_uring selftest

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

On 2/23/26 15:23, Ming Lei wrote:
> On Sat, Feb 21, 2026 at 6:35 AM Pavel Begunkov <asml.silence@gmail.com> wrote:
>>
>> On 2/20/26 17:45, Alexei Starovoitov wrote:
>>> On Fri, Feb 20, 2026 at 3:41 AM Pavel Begunkov <asml.silence@gmail.com> wrote:
>>>>
>>>> I had such examples, but selftests is not the best place for that.
>>>> It can use abstractions, and I want to make them reusable instead
>>>> of people copy-pasting from selftests.
>>>
>>> Sure, but please still post them as extra patches so it's easier
>>> to see what's the end result.
>>>
>>> Also please reply to that thread:
>>> https://lore.kernel.org/bpf/CALTww28QMg=YXqKWpWLZrLO+xiqOe3LGyput8dx68-dnQsxg=g@mail.gmail.com/
>>>
>>> It's not clear to me whether your io_uring+bpf setup will work
>>> for Xiao's use case.
>>> I don't think we need 2 ways of doing it.
>>
>> We discussed this with Ming on the list before, that's one of the use
>> cases I target as well, there is no reason why it shouldn't work. The
>> difference is that this approach gives a flexible framework for
>> extensibility and covers a good bunch of other needs, which is exactly
>> the reason I moved from a BPF opcode approach, while Ming's proposal is
>> more specific but argued to be a way easier to plug into ublk servers.
>> If you ask me, we need a solution that covers a broader spectrum of
>> use cases, but I guess it all can be argued in either way.
> 
> One big drawback of  Pavel's approach is that it needs a totally
> different userspace
> implementation for using BPF, which is just hard to use in existing
> io_uring applications.

Not really, it depends on how you write it. If you need to rewrite CQ
handling in BPF, e.g. parsing CQEs and stopping at interesting completions
to calculate checksums / etc. with BPF, then I get it, it's more involved.
It could be useful for other reasons as well, but that's beside the point.
But you can do that without ever touching CQ/SQ in BPF, for example,
execute all your BPF work at the beginning of a syscall and indicate
about this work via user-BPF shared memory.

The downside is breaking links in two if you use those, but perhaps
you remember my opinion on io_uring links, with the amount of uAPI
side effects and locking complexity it adds to io_uring while not
being too flexible, I'd rather replace them with something more
generic, like this BPF struct_ops.

In either case, I need it for a broader set of issues. It should
work for things like checksumming / other manipulations of
internally installed registered buffers, but even without it,
there are enough use cases to justify that.

> But BPF opcode approach is seamless with existing io_uring applications, because
> it simply uses existing io_uring interface.
-- 
Pavel Begunkov