From: Alessio Faina <alessio.faina@canonical.com>
To: Andrea Mayer <andrea.mayer@uniroma2.it>
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, horms@kernel.org, shuah@kernel.org,
netdev@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org, hangbin.liu@linux.dev,
stefano.salsano@uniroma2.it
Subject: Re: [PATCH net] selftest/net: skip srv6_end_d[t/x][4/6]_*_test.sh if iproute2 too old
Date: Tue, 1 Sep 2026 16:18:56 +0200 [thread overview]
Message-ID: <apbe0PAvaes977l-@cicciput> (raw)
In-Reply-To: <20260829231150.8180c09f6874606eb49d0243@uniroma2.it>
On Sat, Aug 29, 2026 at 11:11:50PM +0200, Andrea Mayer wrote:
> On Fri, 28 Aug 2026 18:04:41 +0200
> Alessio Faina <alessio.faina@canonical.com> wrote:
>
> > [snip]
> >
>
> Hi Alessio,
>
> > I tried multiple methods:
> > the first approach is yours, but I can see the following error with any iproute2
> > version I'm using (I tried 5.5 to 5.18): when running
> > "ip -netns ${rtdst_name}" command, it always returns
> >
> > RTNETLINK answers: File exists
> > 2
>
> EEXIST means that the object is already there, and says nothing about
> vrftable. When ip does not know vrftable it refuses the command itself,
> with the error you showed earlier: either "to" is duplicate,
> or "vrftable" is a garbage.
>
> In a netns created by the check there is nothing to collide with, so EEXIST
> does not come from the way I suggested. The full command and output would
> settle it.
>
> > I tried the following approach as well,
> >
> > # set the decap route for decapsulating packets which arrive from
> > # the rtdst router and destined to the hsdst host.
> > - ip -netns ${rtdst_name} -6 route add ${vpn_sid}/128 table ${LOCALSID_TABLE_ID} \
> > - encap seg6local action End.DT4 vrftable ${tid} dev vrf-${tid}
> > + if ! ip -netns ${rtdst_name} -6 route add ${vpn_sid}/128 table ${LOCALSID_TABLE_ID} \
> > + encap seg6local action End.DT4 vrftable ${tid} dev vrf-${tid} 2>/dev/null; then
> > + echo "SKIP: SRv6 End.DT4 vrftable not supported in iproute2"
> > + cleanup
> > + exit "${ksft_skip}"
> > + fi
> >
> > where the test is checked at vrftable creation time, and it would
> > cleanup and exit as expected from standard tests.
> >
> > But obviously this gets the same RTNETLINK answer as an error.
> >
>
> This is a setup step, not a check. The skip decision is taken while the
> topology is being built, because setup_vpn_config() is called several times
> inside setup(). The check should run before setup(), once.
>
> The way I suggested runs the route add with vrftable in a throwaway netns,
> created and removed by the check itself.
> test_encap_lookup_supp_or_ksft_skip() in srv6_encap_lookup_l3vpn_test.sh
> has that shape: it creates the netns, adds the device it needs, tries its
> route, and on failure cleans up and exits ksft_skip. For the dt4 and dt6
> tests that device is a vrf bound to the table passed to vrftable, and the
> netns also needs the strict mode.
>
> > Then another approach came to my mind, and it seems to be quite reliable.
> > Practically checking if the ip command contains the string "vrftable"
> > using the "strings" command, and if not, skip the test.
> >
> > Something like this:
> >
> > +test_iproute2_vrftable_supp_or_ksft_skip()
> > +{
> > + if ! strings $(command -v ip) | grep -q "vrftable"; then
> > + echo "SKIP: SRv6 End.DT4 vrftable not supported in iproute2"
> > + exit "${ksft_skip}"
> > + fi
> > +}
> > +
> >
> > What do you think about it?
>
> I would rather not add a new tool dependency to these two tests. The
> route add uses ip, which the test needs anyway.
>
> Ciao,
> Andrea
Hi Andrea,
I understand, what you say makes sense; in the end what you originally
suggested seems to be the best approach.
I tried this
+test_iproute2_vrftable_supp_or_ksft_skip()
+{
+ ip netns add __vrftable_test 2>/dev/null
+ ip netns exec __vrftable_test sh -c "echo 1 > /proc/sys/net/vrf/strict_mode"
+ ip -netns __vrftable_test link add vrf-100 type vrf table 100
+ ip -netns __vrftable_test link set vrf-100 up
+ if ! ip -netns __vrftable_test -6 route add fc00::1/128 \
+ encap seg6local action End.DT4 vrftable 100 dev vrf-100 2>/dev/null; then
+ ip netns del __vrftable_test 2>/dev/null
+ echo "SKIP: SRv6 vrftable not supported in iproute2"
+ exit "${ksft_skip}"
+ fi
+ ip netns del __vrftable_test 2>/dev/null
+}
+
+test_iproute2_vrftable_supp_or_ksft_skip
+
and seems to be behaving as expected in my environment for multiple
iproute2 versions. If you're happy with it I'll send a v2 to net-next.
Kind regards,
-Alessio Faina
next prev parent reply other threads:[~2026-09-01 14:19 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-24 9:15 [PATCH net] selftest/net: skip srv6_end_d[t/x][4/6]_*_test.sh if iproute2 too old Alessio Faina
2026-08-25 8:39 ` Hangbin Liu
2026-08-25 8:45 ` Hangbin Liu
2026-08-25 22:01 ` Andrea Mayer
2026-08-26 11:49 ` Alessio Faina
2026-08-27 1:07 ` Andrea Mayer
2026-08-27 9:56 ` Alessio Faina
2026-08-28 2:23 ` Andrea Mayer
2026-08-28 16:04 ` Alessio Faina
2026-08-29 21:11 ` Andrea Mayer
2026-09-01 14:18 ` Alessio Faina [this message]
2026-09-02 18:25 ` Andrea Mayer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=apbe0PAvaes977l-@cicciput \
--to=alessio.faina@canonical.com \
--cc=andrea.mayer@uniroma2.it \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hangbin.liu@linux.dev \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shuah@kernel.org \
--cc=stefano.salsano@uniroma2.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.