Re: [PATCH 0/3] extra io_uring BPF examples

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

On 2/24/26 18:54, Alexei Starovoitov wrote:
> On Mon, Feb 23, 2026 at 7:06 AM Pavel Begunkov <asml.silence@gmail.com> wrote:
>>
>> On 2/23/26 14:39, Jens Axboe wrote:
>>> 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.
>>
>> What kind of support do you mean? Installation, removal, other BPF
>> management is all on the libbpf side, e.g. skeleton open/load/etc.,
>> and with it generating new structures for each of them, I'm not sure
>> how to make it into some generic API whether it's liburing or not
>> instead of making users to fill in the gaps, nor I think we should.
>> As for figuring out right helpers and abstractions for BPF program
>> writing, it'll be a gradual process, and I'd rather have it
>> separately, it's not like I can reuse liburing for that.
> 
> The cp and ratelimiter examples make sense to me.
> The 3rd one with xor kfunc is a conversation starter.
> 
> Since liburing already has "cp" in examples/
> I have to agree with Jens that "cp" as bpf prog should be there as well.
> Spreading the examples across github and kernel tree won't work well.
> We learned this lesson with samples/bpf/ long ago.
Urgh, that's the reason why I don't want these 3 to be merged. Neither
I was excited about wiring any examples as selftests, but you asked for
something that can be posted together a while back, and I obliged. Maybe
there is some misunderstanding? and if nobody needs these selftests, I'd
rather drop them entirely.

Ok, I'll copy paste the cp example to liburing. And there is no BPF
support I can add to liburing as it's all mandated by libbpf. But I
hope nobody says that I can't use io_uring outside of liburing and
anything and everything should be shackled to liburing, there are
enough examples showing the opposite.

-- 
Pavel Begunkov