Re: [PATCH net-next v2] selftests: drv-net: add BIG TCP test cases

On Sat, Sep 12, 2026 at 09:32:26AM -0700, Jakub Kicinski wrote:

On Fri, 11 Sep 2026 22:03:27 -0700 Narcisa Vasile wrote:

quoted

Add four new test cases that validate coalescing
under increased size limits (BIG TCP):

big_tcp_data_same
  - validates that equal-sized segments coalesce past
   the legacy IP_MAXPACKET limit.
big_tcp_data_lrg_sml
  - validates that a smaller final segment coalesces into the
    previous chain of large-sized segments while crossing the
    IP_MAXPACKET limit.
big_tcp_tcp_seq
  - validates that a packet with a wrong sequence number doesn't
    coalesce. The test uses a sequence number for which the low 16 bits
    correspond to the correct sequence number to validate against
    truncation bugs, since total aggregate length crosses over the
    legacy size limit for BIG TCP.
big_tcp_large_max
  - validates that coalescing stops at the configured BIG TCP limit.

 
Still failing:

https://netdev-ctrl.bots.linux.dev/logs/vmksft/net-drv-dbg/results/819882/3-gro-sw-py/stdout

https://netdev-ctrl.bots.linux.dev/logs/vmksft/net-drv-dbg/results/819882/3-gro-sw-py-retry/stdout

Grep gro_lib.py for KSFT_MACHINE_SLOW

Are you suggesting to just skip the big tcp test cases on slow machines?
That's the current behavior for the large_* existing tests.

Then the 15x increase is probably unnecessary/too high as well, since
we GRO 64k 128k shouldn't need more than 2x ?

If I skip them in slow envs, then yes, 2x should be enough.
Those pre-existing up-to-64K large tests don't pass either in the run
above. They're skipped, so we don't actually know the proper
timeout value for them in this test envirnoment. From the test run above:

# #           Received {40560 [!=65495]24935 [!=599]599 [!=0]}, Total 3 packets.
# #           /srv/vmksft/testing/wt-18/tools/testing/selftests/net/lib/gro: incorrect number of packets
# # Ignoring ipv4/large_max failure due to slow environment

Instead of skipping them, I was thinking to change the approach and
send packets continuously, enough for more than just one aggregate.
The the test would verify that at least one aggregate passed the 64K boundary.
I'd also keep the increased timeout. What do you think?