From: Jens Axboe <axboe@kernel.dk>
To: Pavel Begunkov <asml.silence@gmail.com>, io-uring@vger.kernel.org
Cc: bpf@vger.kernel.org, Alexei Starovoitov <alexei.starovoitov@gmail.com>
Subject: Re: [PATCH 0/3] extra io_uring BPF examples
Date: Mon, 23 Feb 2026 07:39:23 -0700 [thread overview]
Message-ID: <a7e1f667-04ba-4fe5-b21e-8c47e68213d3@kernel.dk> (raw)
In-Reply-To: <d808f483-3c0f-4323-8faa-0b7d49c539e3@gmail.com>
On 2/23/26 7:32 AM, Pavel Begunkov wrote:
> On 2/23/26 14:14, Jens Axboe wrote:
>> On 2/23/26 7:11 AM, Pavel Begunkov wrote:
>>> NOT FOR INCLUSION
>>>
>>> Alexei asked for extra more realistic examples. This this series is
>>> based on top of v9 of the io_uring BPF series and implemented as
>>> selftests. There could be more, but I stopped with 3 that should
>>> give an idea how it'll be used:
>>>
>>> 1. A QD=1 file copy program that show cases state machine handling.
>>>
>>> 2. A BPF program rate-limiting the number of inflight io_uring request.
>>> That's a good example of what users asked for before but seemed to
>>> be too niche to be plumbed into the main io_uring path.
>>>
>>> 3. A toy example of how BPF can interact with registered buffers.
>>
>> Let's please keep examples in the liburing side, where they can be
>> with the documentation too.
>
> I got you a liburing example
>
> https://github.com/isilence/liburing/tree/bpf-ops-example
Right, but that's just the nop thing, which isn't really interesting
outside of doing basic verification of yes indeed the kernel side works.
> but need to sync with the selftest. I think I'll rather keep the rest
> into a separate repository instead of adding all helpers to liburing,
> which will inevitably do similar things but deviating in API and
> internal details. And it's simpler on dependency management instead
> of requiring libbpf / etc. for liburing. I wanted a space for
> misc io_uring bits that doesn't make sense to keep as core liburing
> anyway.
liburing should have support and documentation. It's not that hard to
check for libbpf in configure and either build the support or not. Once
various feature support ends up being fragmented in the ecosystem THAT
is a mess for users, I'd much rather have it consolidated and deal with
it on the liburing side.
--
Jens Axboe
next prev parent reply other threads:[~2026-02-23 14:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-23 14:11 [PATCH 0/3] extra io_uring BPF examples Pavel Begunkov
2026-02-23 14:12 ` [PATCH 1/3] io_uring/selftests: add BPF'ed cp example Pavel Begunkov
2026-02-23 14:12 ` [PATCH 2/3] io_uring/selftests: add rate limiter BPF program Pavel Begunkov
2026-02-23 14:12 ` [PATCH 3/3] io_uring/selftests: add regbuf xor example Pavel Begunkov
2026-02-23 14:14 ` [PATCH 0/3] extra io_uring BPF examples Jens Axboe
2026-02-23 14:32 ` Pavel Begunkov
2026-02-23 14:39 ` Jens Axboe [this message]
2026-02-23 15:06 ` 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=a7e1f667-04ba-4fe5-b21e-8c47e68213d3@kernel.dk \
--to=axboe@kernel.dk \
--cc=alexei.starovoitov@gmail.com \
--cc=asml.silence@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=io-uring@vger.kernel.org \
/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