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] [thread-next>] [day] [month] [year] [list]

Message-ID: <d26ea97a-1ef8-aee0-d9fb-7ba80ddcdcb0@redhat.com>
Date: Wed, 26 Feb 2025 20:14:43 +0100 (CET)
From: Pablo Martin Medrano <pablmart@...hat.com>
To: Jakub Kicinski <kuba@...nel.org>
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 Mon, 24 Feb 2025, 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.

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.

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

- 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?