netdev - Re: [PATCH net] selftests/net: big_tcp: longer netperf session on slow machines

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250226183913.3666973e@kernel.org>
Date: Wed, 26 Feb 2025 18:39:13 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Pablo Martin Medrano <pablmart@...hat.com>
Cc: Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org, "David S .
 Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Simon
 Horman <horms@...nel.org>, Shuah Khan <shuah@...nel.org>
Subject: Re: [PATCH net] selftests/net: big_tcp: longer netperf session on
 slow machines

On Wed, 26 Feb 2025 20:14:43 +0100 (CET) Pablo Martin Medrano wrote:
> > On Fri, 21 Feb 2025, Jakub Kicinski wrote:
> > > Hm. Wouldn't we ideally specify the flow length in bytes? Instead of
> > > giving all machines 1 sec, ask to transfer ${TDB number of bytes} and
> > > on fast machines it will complete in 1 sec, on slower machines take
> > > longer but have a good chance of still growing the windows?
> 
> Testing in my development machine, the equivalent to 1 second worth of
> packages is around 1000000000, changing -l 1 to -l -1000000000 resulted
> in the same time and the same test behaviour.

Seems like a lot! If I'm looking right it's 1G. Could you try 128M?

> To force the failure I generate load using stress-ng --sock <n> with
> increasing values of n. The values for n needed for the test to fail are
> higher with the 'fixed number of packages' approach.
> 
> Testing in the original 'slow system' it increases the time of each
> iteration to about 10 seconds, and it does not fail in the same
> circumstances.
> 
> But I have some concerns about this approach instead of the xfail on
> slow:
> 
> - If I generate load in the slow system, the "number of packages"
>   approach also fails, so it is not clear how many packages to set.

I wouldn't worry too much about testing overloaded systems.

> - The test maybe slower in slower systems where it previously worked
>   fine.

I think that's still preferable than effectively ignoring failures?

> - The generation of packages and the time for the tcp window to adapt
>   increase linearly? Isn't there the possibility that in future _faster_
>   systems the test fails because the netperf session goes too fast?

I don't know this test well but I think it tries to hit a big TSO
packet, of fixed size. So the difficulty of that will only go down
with the system speed.