linux-toradex.git/tools/testing/selftests/net/lib, branch master Linux kernel for Apalis and Colibri modules selftests: net: py: add test case filtering and listing 2026-04-12T16:09:09+00:00 Jakub Kicinski kuba@kernel.org 2026-04-10T01:39:21+00:00 e46ff213f7a5f5aaebd6bca589517844aa0fe73a When developing new test cases and reproducing failures in existing ones we currently have to run the entire test which can take minutes to finish. Add command line options for test selection, modeled after kselftest_harness.h: -l list tests (filtered, if filters were specified) -t name include test -T name exclude test Since we don't have as clean separation into fixture / variant / test as kselftest_harness this is not really a 1 to 1 match. We have to lean on glob patterns instead. Like in kselftest_harness filters are evaluated in order, first match wins. If only exclusions are specified everything else is included and vice versa. Glob patterns (*, ?, [) are supported in addition to exact matching. Reviewed-by: Willem de Bruijn <willemb@google.com> Tested-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260410013921.1710295-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
When developing new test cases and reproducing failures in
existing ones we currently have to run the entire test which
can take minutes to finish.

Add command line options for test selection, modeled after
kselftest_harness.h:

  -l       list tests (filtered, if filters were specified)
  -t name  include test
  -T name  exclude test

Since we don't have as clean separation into fixture / variant /
test as kselftest_harness this is not really a 1 to 1 match.
We have to lean on glob patterns instead.

Like in kselftest_harness filters are evaluated in order, first
match wins. If only exclusions are specified everything else is
included and vice versa.

Glob patterns (*, ?, [) are supported in addition to exact
matching.

Reviewed-by: Willem de Bruijn <willemb@google.com>
Tested-by: Gal Pressman <gal@nvidia.com>
Reviewed-by: Breno Leitao <leitao@debian.org>
Link: https://patch.msgid.link/20260410013921.1710295-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
selftests: net: py: explicitly forbid multiple ksft_run() calls 2026-04-10T03:38:33+00:00 Jakub Kicinski kuba@kernel.org 2026-04-08T22:19:52+00:00 3d2c3d2eea9acdbee5b5742d15d021069b49d3f9 People (do people still write code or is it all AI?) seem to not get that ksft_run() can only be called once. If we call it multiple times KTAP parsers will likely cut off after the first batch has finished. Link: https://patch.msgid.link/20260408221952.819822-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
People (do people still write code or is it all AI?) seem to not
get that ksft_run() can only be called once. If we call it
multiple times KTAP parsers will likely cut off after the first
batch has finished.

Link: https://patch.msgid.link/20260408221952.819822-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
selftests: net: py: color the basics in the output 2026-04-07T00:47:59+00:00 Jakub Kicinski kuba@kernel.org 2026-04-02T21:54:44+00:00 3b45559f6c0af0eaf8a91dfc1037a423337cf21d Sometimes it's hard to spot the ok / not ok lines in the output. This is especially true for the GRO tests which retries a lot so there's a wall of non-fatal output printed. Try to color the crucial lines green / red / yellow when running in a terminal. Acked-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Willem de Bruijn <willemb@google.com> Acked-by: Joe Damato <joe@dama.to> Link: https://patch.msgid.link/20260402215444.1589893-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
Sometimes it's hard to spot the ok / not ok lines in the output.
This is especially true for the GRO tests which retries a lot
so there's a wall of non-fatal output printed.

Try to color the crucial lines green / red / yellow when running
in a terminal.

Acked-by: Stanislav Fomichev <sdf@fomichev.me>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Acked-by: Joe Damato <joe@dama.to>
Link: https://patch.msgid.link/20260402215444.1589893-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
selftests: drv-net: gro: add a test for bad IPv4 csum 2026-04-03T22:05:45+00:00 Jakub Kicinski kuba@kernel.org 2026-04-02T21:00:00+00:00 764d0833e795916ffe33906ace17bab027c093f8 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 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>
selftests: drv-net: gro: test ip6ip6 2026-04-03T22:05:44+00:00 Jakub Kicinski kuba@kernel.org 2026-04-02T20:59:59+00:00 9a84a4047df79f7f58a4915abaf09d1089103233 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> 
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>
selftests: drv-net: gro: make large packet math more precise 2026-04-03T22:05:44+00:00 Jakub Kicinski kuba@kernel.org 2026-04-02T20:59:58+00:00 024597cc2077e36dc69327e46fa6dfb1cd0885cd 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> 
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>
selftests: drv-net: gro: remove TOTAL_HDR_LEN 2026-04-03T22:05:44+00:00 Jakub Kicinski kuba@kernel.org 2026-04-02T20:59:57+00:00 166b0cc6df8c8bd961058aa3ed0c2d1a2bdaffca 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> 
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>
selftests: drv-net: gro: prepare for ip6ip6 support 2026-04-03T22:05:43+00:00 Jakub Kicinski kuba@kernel.org 2026-04-02T20:59:56+00:00 5469b695f23642611c47e31329025a21de86c629 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> 
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>
selftests: drv-net: gro: always wait for FIN in the capacity test 2026-04-03T22:05:43+00:00 Jakub Kicinski kuba@kernel.org 2026-04-02T20:59:55+00:00 d97348474708d5f67bec6da28c2e14e12598b965 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> 
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>
selftests: drv-net: gro: add 1 byte payload test 2026-04-03T22:05:43+00:00 Jakub Kicinski kuba@kernel.org 2026-04-02T20:59:54+00:00 436ea8a1b7ed1328cf24cebb3ebaa21aa0c6a81a 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> 
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>