We have a test for coalescing with bad TCP checksum, let's also test bad IPv4 header checksum. Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260402210000.1512696-9-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
We explicitly test ipip encap. Let's add ip6ip6, too. Having just ipip seems like favoring IPv4 which we should not do :) Testing all combinations is left for future work, not sure it's actually worth it. Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260402210000.1512696-8-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When constructing the packets for large_* test cases we use a static value for packet count and MSS. It works okay for ipv4 vs ipv6 but the gap between ipv4 and ip6ip6 is going to be quite significant. Make the defines calculate the worst case values, those are only used for sizing stack arrays. Create helpers for calculating precise values based on the exact test case. Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260402210000.1512696-7-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Willem points out TOTAL_HDR_LEN is identical to MAX_HDR_LEN. This seems to have been the case ever since the test was added. Replace the uses of TOTAL_HDR_LEN with MAX_HDR_LEN, MAX seems more common for what this value is. Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260402210000.1512696-6-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Try to use already calculated offsets and not depend on the ipip flag as much. This patch should not change any functionality, it's just a cleanup to make ip6ip6 support easier. Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260402210000.1512696-5-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The new capacity/order test exits as soon as it sees the expected packet sequence. This may allow the "flushing" FIN packet to spill over to the next test. Let's always wait for the FIN before exiting. Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260402210000.1512696-4-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Small IPv4 packets get padded to 60B, this may break / confuse some buggy implementations. Add a test to coalesce a 1B payload. Keep this separate from the lrg_sml test because I suspect some implementations may not handle this case (treat padded frames as ineligible for coalescing). Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260402210000.1512696-3-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add a test trying to induce a GRO context timeout followed by another sequence of packets for the same flow. The second burst arrives 100ms after the first one so any implementation (SW or HW) must time out waiting at that point. We expect both bursts to be aggregated successfully but separately. Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260402210000.1512696-2-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add a test to check if the NIC reorders packets if the hit GRO. Link: https://patch.msgid.link/20260318033819.1469350-6-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Test accuracy of GRO stats. We want to cover two potentially tricky cases: - single segment GRO - packets which were eligible but didn't get GRO'd The first case is trivial, teach gro.c to send one packet, and check GRO stats didn't move. Second case requires gro.c to send a lot of flows expecting the NIC to run out of GRO flow capacity. To avoid system traffic noise we steer the packets to a dedicated queue and operate on qstat. Link: https://patch.msgid.link/20260318033819.1469350-5-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>