Re: [PATCH bpf-next v2 0/4] selftests/bpf: convert test_tc_edt.sh into test_progs

["Alexis Lothoré" <alexis.lothore@bootlin.com>]

Hi Alexei, 

On Sat Nov 29, 2025 at 6:46 PM CET, Alexei Starovoitov wrote:
> On Fri, Nov 28, 2025 at 2:27 PM Alexis Lothoré (eBPF Foundation)
> <alexis.lothore@bootlin.com> wrote:

[...]

>> The original test was configured with a 20s duration and a 1% error
>> margin. The new test is configured with 1MB of data being pushed and a
>> 2% error margin, to:
>> - make the duration tolerable in CI
>> - while keeping enough margin for rate measure fluctuations depending on
>>   the CI machines load
>
> Applied, but it's still a bit flaky in my setup.
> Fails like this from time to time when run in parallel with other tests:
> run_test:FAIL:rate error is lower than threshold unexpected rate error
> is lower than threshold: actual 6 > expected 2
> #450     tc_edt:FAIL

Yeah, that's what I was worrying about with this test. For the record, I
tested the v2 using my own fork this time to run GH actions before sending,
rather than opening a dummy PR onto the official GH repo, and this somehow
led to only x86 testing (which passed). I then saw the test failing on the
official CI triggered by the series being posted, in S390. I guess this is
not so suprising, as any qemu other than x86 will likely make tests more
sensitive to CPU load.

Maybe we can afford to raise the admissible error on the effective rate to
something way higher, like 10%. That would validate any rate between
4.5MBps and 5.5MBps, but that's still pretty far from the rates we can
expect if the shaper fails to trigger, so the test would still make sense.

Otherwise, an intermediate test that we could do is setting it as a serial test
and see if it improves things in CI ?

Alexis

-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com