On Wed, 18 Mar 2026 13:29:56 +0100 Justin Iurman <[email protected]> wrote:
> On Tue, Mar 17, 2026 at 11:54 AM Andrea Mayer <[email protected]> > wrote: > > > > On Mon, 16 Mar 2026 17:29:55 +0100 > > Justin Iurman <[email protected]> wrote: > > > > > Extend srv6_hencap_red_l3vpn_test.sh to include checks for the new > > > "tunsrc" feature. > > > > > > Cc: Shuah Khan <[email protected]> > > > Cc: [email protected] > > > Signed-off-by: Justin Iurman <[email protected]> > > > --- > > > .../net/srv6_hencap_red_l3vpn_test.sh | 65 ++++++++++++++----- > > > 1 file changed, 50 insertions(+), 15 deletions(-) > > [snip] > > > > - # Direction hs-1 -> hs-2 (H.Encaps.Red) > > > + # Direction hs-1 -> hs-2 (H.Encaps.Red + tunsrc) > > > # - rt-2 (SRv6 End.DT46 behavior) > > > # > > > # Direction hs-2 -> hs-1 (H.Encaps.Red) > > > # - rt-4,rt-3 (SRv6 End behaviors) > > > # - rt-1 (SRv6 End.DT46 behavior) > > > - setup_rt_policy_ipv4 2 1 "" 2 encap.red > > > - setup_rt_policy_ipv4 1 2 "4 3" 1 encap.red > > > + setup_rt_policy_ipv4 2 1 "" 2 encap.red true > > > + setup_rt_policy_ipv4 1 2 "4 3" 1 encap.red false > > > > > > # create an IPv6 VPN between hosts hs-3 and hs-4 > > > # the network path between hs-3 and hs-4 traverses several routers > > > # depending on the direction of traffic. > > > # > > > - # Direction hs-3 -> hs-4 (H.Encaps.Red) > > > + # Direction hs-3 -> hs-4 (H.Encaps.Red + tunsrc) > > > # - rt-2 (SRv6 End Behavior) > > > # - rt-4 (SRv6 End.DT46 behavior) > > > # > > > # Direction hs-4 -> hs-3 (H.Encaps.Red) > > > # - rt-1 (SRv6 End behavior) > > > # - rt-3 (SRv6 End.DT46 behavior) > > > - setup_rt_policy_ipv6 4 3 "2" 4 encap.red > > > - setup_rt_policy_ipv6 3 4 "1" 3 encap.red > > > + setup_rt_policy_ipv6 4 3 "2" 4 encap.red true > > > + setup_rt_policy_ipv6 3 4 "1" 3 encap.red false > > > > > > # testing environment was set up successfully > > > SETUP_ERR=0 > > > > > > The paths marked "true" here were testing the encap.red baseline before > > this change. They need to stay exactly as they were originally. > > Furthermore, if tunsrc is not supported by the kernel running the test, > > the ip route command with tunsrc will fail during setup() (since > > set -e is used), and the entire script dies before any test runs. > > I kinda disagree here: you're not supposed to run the updated > selftests on an old kernel or with an old iproute2 version (versions > are kept aligned). And I also concur with Jakub about degraded > environments on your last comment below. > > > The idea here is to avoid duplicating the entire test suite, while still > > providing dedicated test cases for the new per-route tunsrc. A reasonable > > approach could be adding the tunsrc checks as new, separate test cases > > that run after the baseline ones, leaving the existing paths completely > > untouched. > > > > For example, a dedicated test_tunsrc() function could take care of the > > whole thing for a given path: setting up the tunsrc address, installing > > the route with tunsrc, verifying the behavior, cleaning up, and finally > > restoring the original route. > > Well, I actually thought that this approach would be easier, and would > specifically avoid adding too much code or having duplication. FWIW, I > don't think providing dedicated test cases for the new per-route > tunsrc really makes sense, as it's the same behavior as without > "tunsrc". It doesn't impact the encap baseline by itself, since > nothing in the selftests depends on the outer source address. I'm open > to implement what you suggest, though, it's just that I'm not sure > it's the best way forward. > > What I suggest as next step: I'll ship patch #1 alone, along with the > iproute2-next companion series, so that we don't miss the merge window > and have the feature in 7.1. In parallel, we keep discussing design > choices for the selftest and ship it as soon as we settle. Would you > agree with that plan? > > Cheers, > Justin > Hi Justin, IMHO, the optimal goals should be: 1) have at least a selftest that covers the new feature; 2) re-use *if reasonable* existing selftests; 3) have selftests that run on a reasonable set of kernels and environments, without unreasonably increasing their complexity. I'd prefer to have the selftest shipped together with the feature. I think we could find a reasonable way to integrate the tunsrc checks without overcomplicating the existing selftest. Let me send you an idea offline so we can evaluate it together. I certainly don't want to hold up the tunsrc feature, it's something I find very interesting and that I also discussed at netdev 0x19 (2025). Thanks, Andrea
