public inbox for io-uring@vger.kernel.org
 help / color / mirror / Atom feed
From: Ming Lei <ming.lei@redhat.com>
To: Pavel Begunkov <asml.silence@gmail.com>
Cc: Ming Lei <tom.leiming@gmail.com>,
	 Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	io-uring <io-uring@vger.kernel.org>,  bpf <bpf@vger.kernel.org>,
	Jens Axboe <axboe@kernel.dk>, Xiao Ni <xni@redhat.com>,
	 Caleb Sander Mateos <csander@purestorage.com>
Subject: Re: [PATCH v8 5/5] selftests/io_uring: add a bpf io_uring selftest
Date: Wed, 25 Feb 2026 16:41:38 +0800	[thread overview]
Message-ID: <CAFj5m9L_WPH_du4GMVYGBdYA_NX1kbGtJpAP0hbfuEjuk5faZw@mail.gmail.com> (raw)
In-Reply-To: <ed7b85d0-38d0-413c-a28a-f3b0d1a72a13@gmail.com>

On Tue, Feb 24, 2026 at 12:30 AM Pavel Begunkov <asml.silence@gmail.com> wrote:
>
> 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

I meant SQE has to be allocated & built in bpf prog, then it is inevitable
to move application logic into bpf prog.

If the logic is complicated, it is one big thing.

raid5 is a great example with complicated fast io code path, I'd suggest someone
or Xiao or Caleb, try it. Compare your approach to the bpf opcode and draw
some useful conclusions.  Code should be more convincing.

For bpf opcode approach I believe Xiao has already built an example.


Thanks,
Ming


  reply	other threads:[~2026-02-25  8:41 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-17 11:33 [PATCH v8 0/5] BPF controlled io_uring Pavel Begunkov
2026-02-17 11:33 ` [PATCH v8 1/5] io_uring: introduce callback driven main loop Pavel Begunkov
2026-02-17 11:33 ` [PATCH v8 2/5] io_uring/bpf-ops: implement loop_step with BPF struct_ops Pavel Begunkov
2026-02-17 11:33 ` [PATCH v8 3/5] io_uring/bpf-ops: add kfunc helpers Pavel Begunkov
2026-02-17 11:33 ` [PATCH v8 4/5] io_uring/bpf-ops: implement bpf ops registration Pavel Begunkov
2026-02-17 11:33 ` [PATCH v8 5/5] selftests/io_uring: add a bpf io_uring selftest Pavel Begunkov
2026-02-19 19:01   ` Alexei Starovoitov
2026-02-20 11:41     ` Pavel Begunkov
2026-02-20 17:45       ` Alexei Starovoitov
2026-02-20 22:35         ` Pavel Begunkov
2026-02-23 15:23           ` Ming Lei
2026-02-23 16:26             ` Pavel Begunkov
2026-02-25  8:41               ` Ming Lei [this message]
2026-02-25 11:12                 ` Pavel Begunkov
2026-02-23 14:37         ` Pavel Begunkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFj5m9L_WPH_du4GMVYGBdYA_NX1kbGtJpAP0hbfuEjuk5faZw@mail.gmail.com \
    --to=ming.lei@redhat.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=asml.silence@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=bpf@vger.kernel.org \
    --cc=csander@purestorage.com \
    --cc=io-uring@vger.kernel.org \
    --cc=tom.leiming@gmail.com \
    --cc=xni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox