On Thu, Jul 30, 2026, at 10:46, Paolo Abeni wrote: > On 7/29/26 10:44 PM, Alice Mikityanska wrote: >> On Mon, 27 Jul 2026 at 12:09, Matthieu Baerts <[email protected]> wrote: >>> On 23/07/2026 16:02, Alice Mikityanska wrote: >>>> From: Alice Mikityanska <[email protected]> >>>> >>>> Commit 5cb53743e1ff ("selftests: net: Add a test for BIG TCP in UDP >>>> tunnels") used iptables match comment, which was missed from the CI >>>> kernel config. Add the missing config option. >>> >>> It helps, the CI can now run this test! >>> >>> Reviewed-by: Matthieu Baerts <[email protected]> >>> >>> >>> But I think another follow-up patch is required, because this test is >>> flaky when using a debug kernel config: >>> >>> >>> https://netdev.bots.linux.dev/flakes.html?min-flip=0&tn-needle=big-tcp-tunnels-sh >>> >>> Maybe because wait_local_port_listen() is required after having called >>> netserver? >> >> The issue is hard to reproduce on my machine, but I could reproduce it >> in ~12 hours of non-stop testing in a loop. It reproduces even with >> wait_local_port_listen, so it must be something else. The log above >> (and my repro attempts) shows that it fails in a non-first test, but >> netserver starts only once, before the first test. If the failure was >> due to netserver not being ready, it would fail in the first test. >> I'll keep investigating. > I *think* this kind of flakes are sort of expected for 'performance' > related tests when running on debug kernel: the environment can be > painful slow, and few failed iterations I saw has csum offload disabled > - even lower expected tput. > > AFAICS the target packet number is independent from KSFT_MACHINE_SLOW > and the actual offload setting. Possibly you can tune the target value a > bit WRT the mentioned variables or skip entirely pkts number validation > in the slowest permutation (note that the self-test will still have some > value due to code coverage with sanitizers enabled).
Hmm, the above makes sense for the failures like this: https://netdev-ctrl.bots.linux.dev/logview.html?f=/logs/vmksft/net-dbg/results/754376/28-big-tcp-tunnels-sh/stdout 971 is slightly below than 1000 (even though it's typically 1600-1700 on the CI runners, in this configuration). Tuning the thresholds can help. But I also see failures like this: https://netdev-ctrl.bots.linux.dev/logview.html?f=/logs/vmksft/net-dbg/results/751124/21-big-tcp-tunnels-sh/stdout It's a complete zero, so lowering the threshold won't help here. I could reproduce it on my machine, although it requires hours of retries. I'd like to capture the tcpdump and see what actually happens in this case. > /p
