Re: [PATCH bpf-next] selftests/bpf: Run tc_edt serially

From: Qiliang Yuan

Date: Mon Oct 19 2026 - 02:37:49 EST


On Fri, Oct 16, 2026 at 4:05 PM UTC, Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote:
> The test is flaky without -j too.
> It's in DENYLIST.s390x in CI since Dec 2025:
> https://github.com/kernel-patches/vmtest/pull/418
> and it fails on x86 with ASAN:
> https://github.com/kernel-patches/vmtest/issues/503
> Both jobs run test_progs without -j. serial_ won't help there.

Right. I timed the parts of the measurement on a KASAN kernel, x86_64
VM with 32 vCPUs, 30 runs each, median (max):

before 1st data shaped data after last data
idle 0.7ms (0.9ms) 200.08ms (201.9) 0.4ms (0.7ms)
32 busy loops 1.0ms (4.7ms) 200.08ms (200.4) 0.2ms (0.8ms)

The shaping itself is accurate. What eats the 2% margin, which is 4ms
of the 200ms transfer, is what send_recv_data() does before the first
byte goes out: creating the sender thread and accepting the connection.
That grows with how busy or slow the machine is.

To Alexis' questions: the misses are small, the test reports
"actual 2 > expected 2" and -2.4% was the worst here, and they do come
from CPU load. Widening the margin would only move the line, though, so
v2 [1] starts the measurement at the first packet with data instead,
which the BPF program notes. With 32 busy loops, 100 runs fail 3 times
before and none after.

[1] https://lore.kernel.org/r/20261019-selftests-bpf-tc-edt-serial-v2-1-41c3813e7916@xxxxxxxxx