On Wed, Oct 22, 2025 at 12:52 AM Alexis Lothoré alexis.lothore@bootlin.com wrote:
On Wed Oct 22, 2025 at 9:39 AM CEST, Alexis Lothoré (eBPF Foundation) wrote:
The test_tc_tunnel.sh script checks that a large variety of tunneling mechanisms handled by the kernel can be handled as well by eBPF programs. While this test shares similarities with test_tunnel.c (which is already integrated in test_progs), those are testing slightly different things:
- test_tunnel.c creates a tunnel interface, and then get and set tunnel keys in packet metadata, from BPF programs.
- test_tc_tunnels.sh manually parses/crafts packets content
Bring the tests covered by test_tc_tunnel.sh into the test_progs framework, by creating a dedicated test_tc_tunnel.sh. This new test defines a "generic" runner which, for each test configuration:
- will configure the relevant veth pair, each of those isolated in a dedicated namespace
- will check that traffic will fail if there is only an encapsulating program attached to one veth egress
- will check that traffic succeed if we enable some decapsulation module on kernel side
- will check that traffic still succeeds if we replace the kernel decapsulation with some eBPF ingress decapsulation.
Example of the new test execution:
# ./test_progs -a tc_tunnel #447/1 tc_tunnel/ipip_none:OK #447/2 tc_tunnel/ipip6_none:OK #447/3 tc_tunnel/ip6tnl_none:OK #447/4 tc_tunnel/sit_none:OK #447/5 tc_tunnel/vxlan_eth:OK #447/6 tc_tunnel/ip6vxlan_eth:OK #447/7 tc_tunnel/gre_none:OK #447/8 tc_tunnel/gre_eth:OK #447/9 tc_tunnel/gre_mpls:OK #447/10 tc_tunnel/ip6gre_none:OK #447/11 tc_tunnel/ip6gre_eth:OK #447/12 tc_tunnel/ip6gre_mpls:OK #447/13 tc_tunnel/udp_none:OK #447/14 tc_tunnel/udp_eth:OK #447/15 tc_tunnel/udp_mpls:OK #447/16 tc_tunnel/ip6udp_none:OK #447/17 tc_tunnel/ip6udp_eth:OK #447/18 tc_tunnel/ip6udp_mpls:OK #447 tc_tunnel:OK Summary: 1/18 PASSED, 0 SKIPPED, 0 FAILED
Signed-off-by: Alexis Lothoré (eBPF Foundation) alexis.lothore@bootlin.com
A note about test duration: the overall test duration, in my setup (x86 qemu-based setup, running on x86), is around 13s. Reviews on similar series ([1]) shows that such a duration is not really desirable for CI integration. I checked how to reduce it, and it appears that most of it is due to the fact that for each subtest, we verify that if we insert bpf encapsulation (egress) program, and nothing on server side, we properly fail to connect client to server. This test then relies on timeout connection, and I already reduced it as much as possible, but I guess going below the current value (500ms) will just start to make the whole test flaky.
I took this "check connection failure" from the original script, and kind of like it for its capacity to detect false negatives, but should I eventually get rid of it ?
I vote to get rid of it. I'd rather have test_progs that are quick enough to execute for CI and for all developers then more in depth coverage for the corner case. Note that for the verifier range test we randomize the test coverage, since the whole permutation takes hours to run. Instead we randomly pick a couple tests and run only those. Since CI runs for every patch the overall coverage is good enough. Would something like that possible here ? and in the other xsk test?