netdev - Re: [PATCH net-next 00/12] selftests: drv-net: convert GRO and Toeplitz tests to work for drivers in NIPA

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20251117205609.4b0fa035@kernel.org>
Date: Mon, 17 Nov 2025 20:56:09 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com,
 pabeni@...hat.com, andrew+netdev@...n.ch, horms@...nel.org,
 shuah@...nel.org, sdf@...ichev.me, krakauer@...gle.com,
 linux-kselftest@...r.kernel.org
Subject: Re: [PATCH net-next 00/12] selftests: drv-net: convert GRO and
 Toeplitz tests to work for drivers in NIPA

On Mon, 17 Nov 2025 21:11:31 -0500 Willem de Bruijn wrote:
> > Note that neither GRO nor the Toeplitz test fully passes for me on
> > any HW I have access to. But this is unrelated to the conversion.  
> 
> You observed the same failures with the old and new tests? Are they
> deterministic failures or flakes.

Deterministic for Toeplitz - all NICs I have calculate the Rx 
hash the same as the test for at least one of traffic types. 
But none of them exactly as the test is expecting.
One IIRC also uses non-standard RSS indir table pattern by default.
The indirection table will be a trivial fix.

For HW-GRO I investigated less closely I mostly focused on making sure
netdevsim is solid as a replacement for veth. There was more flakiness
on HW (admittedly I was running inter-dc-building). But the failures
looked rather sus - the test was reporting that packets which were
not supposed to be coalesced got coalesced.

BTW it's slightly inconvenient that we disable HW-GRO when normal GRO
is disabled :( Makes it quite hard to run the test to check device
behavior. My current plan is to rely on device counters to check
whether traffic is getting coalesced but better ideas most welcome :(

> > This series is not making any real functional changes to the tests,
> > it is limited to improving the "test harness" scripts.
> 
> No significant actionable comments, just a few trivial typos.

Thanks!