asses when running as a
server.
Tested: Ran `gro.sh -t large` 100 times with and without this change.
Passed 100/100 with and 64/100 without. Ran inside strace to increase
flakiness.
Signed-off-by: Kevin Krakauer
---
tools/testing/selftests/net/gro.c | 8 +---
tools/testing/selftests/
On Thu, Feb 27, 2025 at 11:20:15AM -0500, Willem de Bruijn wrote:
> > ---
> > tools/testing/selftests/net/gro.sh | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/testing/selftests/net/gro.sh
> > b/tools/testing/selftests/net/gro.sh
> > index 02c21ff4ca81..aa
Thanks for the review! I'll split this up. Do you think it's better as two
patchsets -- one for stability/deflaking, one for return value and output
cleanup -- or as a single patchset with several commits?
> To be clear - are you running this over veth or a real device?
Over a veth.
>> Set the d
gro.c:main no longer erroneously claims a test passes when running as a
sender.
Tested: Ran `gro.sh -t large` to verify the sender no longer prints a
status.
Signed-off-by: Kevin Krakauer
---
tools/testing/selftests/net/gro.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff
flushed prematurely. This also lets us reduce the gro_flush_timeout
from 1ms to 100us.
Tested: Ran `gro.sh -t large` 1000 times. There were no failures with
this change. Ran inside strace to increase flakiness.
Signed-off-by: Kevin Krakauer
---
tools/testing/selftests/net/gro.sh| 4
Modify gro.sh to return a useful exit code when the -t flag is used. It
formerly returned 0 no matter what.
Tested: Ran `gro.sh -t large` and verified that test failures return 1.
Signed-off-by: Kevin Krakauer
---
tools/testing/selftests/net/gro.sh | 3 ++-
1 file changed, 2 insertions(+), 1
x27;t updated.
v1: https://lore.kernel.org/netdev/20250218164555.1955400-1-kraka...@google.com/
Kevin Krakauer (3):
selftests/net: have `gro.sh -t` return a correct exit code
selftests/net: only print passing message in GRO tests when tests pass
selftests/net: deflake GRO tests
tools/te
On Mon, Feb 24, 2025 at 12:48:30PM -0800, Jakub Kicinski wrote:
> With msec-long deferrals we'll flush due to jiffies change. At least
> that explains a bit. Could you maybe try lower timeouts than 1msec?
> Previously we'd just keep partially-completed packets in GRO for up
> to 1msec, now we'll d
8 matches
Mail list logo