Hello,
this is a (late) v2 to my first attempt to convert the test_tc_edt
script to test_progs. This new version is way simpler, thanks to
Martin's suggestion about properly using the existing network_helpers
rather than reinventing the wheel. It also fixes a small bug in the
measured effective rate.

The converted test roughly follows the original script logic, with two
veths in two namespaces, a TCP connection between a client and a server,
and the client pushing a specific amount of data. Time is recorded
before and after the transmission to compute the effective rate.

There are two knobs driving the robustness of the test in CI:
- the amount of pushed data (the higher, the more precise is the
  effective rate)
- the tolerated error margin

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

This has been run multiple times locally to ensure that those values are
sane, and once in CI before sending the series, but I suggest to let it
live a few days in CI to see how it really behaves. 

Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
---
Changes in v2:
- drop custom client/server management
- update bpf program now that server pushes data
- fix effective rate computation
- Link to v1: https://lore.kernel.org/r/20251031-tc_edt-v1-0-5d34a5823144@bootlin.com

---
Alexis Lothoré (eBPF Foundation) (4):
      selftests/bpf: rename test_tc_edt.bpf.c section to expose program type
      selftests/bpf: integrate test_tc_edt into test_progs
      selftests/bpf: remove test_tc_edt.sh
      selftests/bpf: do not hardcode target rate in test_tc_edt BPF program

 tools/testing/selftests/bpf/Makefile               |   2 -
 .../testing/selftests/bpf/prog_tests/test_tc_edt.c | 145 +++++++++++++++++++++
 tools/testing/selftests/bpf/progs/test_tc_edt.c    |  11 +-
 tools/testing/selftests/bpf/test_tc_edt.sh         | 100 --------------
 4 files changed, 151 insertions(+), 107 deletions(-)
---
base-commit: 233a075a1b27070af76d64541cf001340ecff917
change-id: 20251030-tc_edt-3ea8e8d3d14e

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

On Fri, Nov 28, 2025 at 2:27 PM Alexis Lothoré (eBPF Foundation)
<alexis.lothore@bootlin.com> wrote:
>
> Hello,
> this is a (late) v2 to my first attempt to convert the test_tc_edt
> script to test_progs. This new version is way simpler, thanks to
> Martin's suggestion about properly using the existing network_helpers
> rather than reinventing the wheel. It also fixes a small bug in the
> measured effective rate.
>
> The converted test roughly follows the original script logic, with two
> veths in two namespaces, a TCP connection between a client and a server,
> and the client pushing a specific amount of data. Time is recorded
> before and after the transmission to compute the effective rate.
>
> There are two knobs driving the robustness of the test in CI:
> - the amount of pushed data (the higher, the more precise is the
>   effective rate)
> - the tolerated error margin
>
> 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

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