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

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

On 2/19/26 19:01, Alexei Starovoitov wrote:
> On Tue, Feb 17, 2026 at 3:33 AM Pavel Begunkov <asml.silence@gmail.com> wrote:
>> +
>> +static inline void write_stats(int idx, unsigned int v)
>> +{
>> +       u32 key = idx;
>> +       u64 *val;
>> +
>> +       val = bpf_map_lookup_elem(&res_map, &key);
>> +       if (val)
>> +               *val += v;
>> +}
> 
> Since these examples will be copied around, let's use
> good coding practices. Use properly named global variables
> for stats and counters, and drop this opaque array.

ok

...
>> +       unsigned to_wait = cq_hdr->tail - cq_hdr->head;
>> +       to_wait = t_min(to_wait, CQ_ENTRIES);
>> +       for (int i = 0; i < to_wait; i++) {
>> +               struct io_uring_cqe *cqe = &cqes[cq_hdr->head & (CQ_ENTRIES - 1)];
>> +
>> +               if (cqe->user_data != REQ_TOKEN) {
>> +                       write_result(-3);
>> +                       return IOU_LOOP_STOP;
>> +               }
>> +               cq_hdr->head++;
>> +       }
> 
> CQ_ENTRIES is just 8.
> Is it enough for real progs?
> Does the above approach scale ?

Depends on the workload. If you're keeping queue depth 8 with a
storage workload, it's all you need, and those don't go too high.
For net recv workloads, it's batched well if you get 8-16 CQEs per
wait, but unfortunately too often it's close to 1. You'd still bump
the CQ size in cases there are bursts in traffic.

We can come up with cases when it's higher, but what's important is
that you don't need to process all CQEs in a single BPF call. I bound
the loop at CQ_ENTRIES for convenience, but the user can set the CQ
size to whatever is needed, process some capped number every time,
and finish the rest if any next time it's called. E.g.

CQ_ENTRIES = 2^14
const max_cqes_batch = 32;

cqes_to_process = cq_hdr->tail - cq_hdr->head;
cqes_to_process = min(cqes_to_process, max_cqes_batch);
process_cqes_nr(cqes_to_process, ...);

if (cqes_left)
	to_wait = 0;

I'll make the CQ size a load time constant and clean up the
program, should make it a better example.

> I mean the above works as a bounded loop because loop
> count is small, but for 100+ you want open coded iterators.

Sure, but let's do that as a follow up when it's needed?

> In general all progs seem to be toy progs.
> Would be good to have something more realistic.

The other two programs are not toys but rather tests. Nop requests in
this one do nothing useful, but that'll be a good queue processing
starting template. Replace nops with reads and it's doing actual IO.
Add writes requests with some offset logic and it copies data b/w files.
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.

-- 
Pavel Begunkov