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

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

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.

-- 
Pavel Begunkov