Re: [PATCH net-next] selftests: net: Add a missing config option

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