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

[Ming Lei <tom.leiming@gmail.com>]

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.

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

Thanks,
Ming Lei