From: David Ahern <dsahern@gmail.com>
To: Andrea Mayer <andrea.mayer@uniroma2.it>,
"David S. Miller" <davem@davemloft.net>,
Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
David Ahern <dsahern@kernel.org>,
Jakub Kicinski <kuba@kernel.org>, Shuah Khan <shuah@kernel.org>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-kselftest@vger.kernel.org
Cc: Stefano Salsano <stefano.salsano@uniroma2.it>,
Paolo Lungaroni <paolo.lungaroni@uniroma2.it>,
Ahmed Abdelsalam <ahabdels.dev@gmail.com>
Subject: Re: [RFC net-next 1/2] seg6: add support for SRv6 End.DT46 Behavior
Date: Tue, 8 Jun 2021 19:15:19 -0600 [thread overview]
Message-ID: <548983f7-a06c-ea80-0906-88231851bc17@gmail.com> (raw)
In-Reply-To: <20210608104017.21181-2-andrea.mayer@uniroma2.it>
On 6/8/21 4:40 AM, Andrea Mayer wrote:
> IETF RFC 8986 [1] includes the definition of SRv6 End.DT4, End.DT6, and
> End.DT46 Behaviors.
>
> The current SRv6 code in the Linux kernel only implements End.DT4 and
> End.DT6 which can be used respectively to support IPv4-in-IPv6 and
> IPv6-in-IPv6 VPNs. With End.DT4 and End.DT6 it is not possible to create a
> single SRv6 VPN tunnel to carry both IPv4 and IPv6 traffic.
>
> The proposed End.DT46 implementation is meant to support the decapsulation
> of IPv4 and IPv6 traffic coming from a single SRv6 tunnel.
> The implementation of the SRv6 End.DT46 Behavior in the Linux kernel
> greatly simplifies the setup and operations of SRv6 VPNs.
>
> The SRv6 End.DT46 Behavior leverages the infrastructure of SRv6 End.DT{4,6}
> Behaviors implemented so far, because it makes use of a VRF device in
> order to force the routing lookup into the associated routing table.
>
> To make the End.DT46 work properly, it must be guaranteed that the routing
> table used for routing lookup operations is bound to one and only one VRF
> during the tunnel creation. Such constraint has to be enforced by enabling
> the VRF strict_mode sysctl parameter, i.e.:
>
> $ sysctl -wq net.vrf.strict_mode=1
>
> Note that the same approach is used for the SRv6 End.DT4 Behavior and for
> the End.DT6 Behavior in VRF mode.
>
> The command used to instantiate an SRv6 End.DT46 Behavior is
> straightforward, i.e.:
>
> $ ip -6 route add 2001:db8::1 encap seg6local action End.DT46 vrftable 100 dev vrf100.
>
> [1] https://www.rfc-editor.org/rfc/rfc8986.html#name-enddt46-decapsulation-and-s
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Performance and impact of SRv6 End.DT46 Behavior on the SRv6 Networking
> =======================================================================
>
> This patch aims to add the SRv6 End.DT46 Behavior with minimal impact on
> the performance of SRv6 End.DT4 and End.DT6 Behaviors.
> In order to verify this, we tested the performance of the newly introduced
> SRv6 End.DT46 Behavior and compared it with the performance of SRv6
> End.DT{4,6} Behaviors, considering both the patched kernel and the kernel
> before applying the End.DT46 patch (referred to as vanilla kernel).
>
> In details, the following decapsulation scenarios were considered:
>
> 1.a) IPv6 traffic in SRv6 End.DT46 Behavior on patched kernel;
> 1.b) IPv4 traffic in SRv6 End.DT46 Behavior on patched kernel;
> 2.a) SRv6 End.DT6 Behavior (VRF mode) on patched kernel;
> 2.b) SRv6 End.DT4 Behavior on patched kernel;
> 3.a) SRv6 End.DT6 Behavior (VRF mode) on vanilla kernel (without the
> End.DT46 patch);
> 3.b) SRv6 End.DT4 Behavior on vanilla kernel (without the End.DT46 patch).
>
> All tests were performed on a testbed deployed on the CloudLab [2]
> facilities. We considered IPv{4,6} traffic handled by a single core (at 2.4
> GHz on a Xeon(R) CPU E5-2630 v3) on kernel 5.13-rc1 using packets of size
> ~ 100 bytes.
>
> Scenario (1.a): average 684.70 kpps; std. dev. 0.7 kpps;
> Scenario (1.b): average 711.69 kpps; std. dev. 1.2 kpps;
> Scenario (2.a): average 690.70 kpps; std. dev. 1.2 kpps;
> Scenario (2.b): average 722.22 kpps; std. dev. 1.7 kpps;
> Scenario (3.a): average 690.02 kpps; std. dev. 2.6 kpps;
> Scenario (3.b): average 721.91 kpps; std. dev. 1.2 kpps;
>
> Considering the results for the patched kernel (1.a, 1.b, 2.a, 2.b) we
> observe that the performance degradation incurred in using End.DT46 rather
> than End.DT6 and End.DT4 respectively for IPv6 and IPv4 traffic is minimal,
> around 0.9% and 1.5%. Such very minimal performance degradation is the
> price to be paid if one prefers to use a single tunnel capable of handling
> both types of traffic (IPv4 and IPv6).
>
> Comparing the results for End.DT4 and End.DT6 under the patched and the
> vanilla kernel (2.a, 2.b, 3.a, 3.b) we observe that the introduction of the
> End.DT46 patch has no impact on the performance of End.DT4 and End.DT6.
>
> [2] https://www.cloudlab.us
>
> Signed-off-by: Andrea Mayer <andrea.mayer@uniroma2.it>
> ---
> include/uapi/linux/seg6_local.h | 2 +
> net/ipv6/seg6_local.c | 94 +++++++++++++++++++++++++--------
> 2 files changed, 74 insertions(+), 22 deletions(-)
>
Reviewed-by: David Ahern <dsahern@kernel.org>
next prev parent reply other threads:[~2021-06-09 1:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-08 10:40 [RFC net-next 0/2] seg6: add support for SRv6 End.DT46 Behavior Andrea Mayer
2021-06-08 10:40 ` [RFC net-next 1/2] " Andrea Mayer
2021-06-09 1:15 ` David Ahern [this message]
2021-06-08 10:40 ` [RFC net-next 2/2] selftests: seg6: add selftest " Andrea Mayer
2021-06-09 1:16 ` David Ahern
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=548983f7-a06c-ea80-0906-88231851bc17@gmail.com \
--to=dsahern@gmail.com \
--cc=ahabdels.dev@gmail.com \
--cc=andrea.mayer@uniroma2.it \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=paolo.lungaroni@uniroma2.it \
--cc=shuah@kernel.org \
--cc=stefano.salsano@uniroma2.it \
--cc=yoshfuji@linux-ipv6.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox