[ovs-dev] [PATCH 3/8] datapath: backport: allow output of MPLS packets on tunnel vports

Jesse Gross jesse at kernel.org
Mon Jul 18 14:35:51 UTC 2016


On Mon, Jul 18, 2016 at 4:24 AM, Pravin B Shelar <pshelar at ovn.org> wrote:
> Upstream commit:
>     commit fe3a5f6c795810edb1646a840fec3c8c350c2a4e
>     Author: Simon Horman <simon.horman at netronome.com>
>
>     openvswitch: allow output of MPLS packets on tunnel vports
>
>     Currently output of MPLS packets on tunnel vports is not allowed by Open
>     vSwitch. This is because historically encapsulation was done in such a way
>     that the inner_protocol field of the skb needed to hold the inner protocol
>     for both MPLS and tunnel encapsulation in order for GSO segmentation to be
>     performed correctly.
>
>     Since b2acd1dc3949 ("openvswitch: Use regular GRE net_device instead of
>     vport") Open vSwitch makes use of lwt to output to tunnel netdevs which
>     perform encapsulation. As no drivers expose support for MPLS offloads this
>     means that GSO packets are segmented in software by validate_xmit_skb(),
>     which is called from __dev_queue_xmit(), before tunnel encapsulation occurs.
>     This means that the inner protocol of MPLS is no longer needed by the time
>     encapsulation occurs and the contention on the inner_protocol field of the
>     skb no longer occurs.
>
>     Thus it is now safe to output MPLS to tunnel vports.
>
>     Signed-off-by: Simon Horman <simon.horman at netronome.com>
>     Reviewed-by: Jesse Gross <jesse at kernel.org>
>     Signed-off-by: David S. Miller <davem at davemloft.net>
>
> Signed-off-by: Pravin B Shelar <pshelar at ovn.org>

I'm still somewhat concerned about this since it makes
USE_UPSTREAM_TUNNEL effectively a user-facing toggle - the effects of
it will be visible all the way out to the OpenFlow layer since it will
be change what flows can be installed (and work). If we need to
continue to bump up the kernel version where we use our own tunneling
then it will keep changing whether these flows work.

I think the ideal thing to would be to actually run the offload code
before transmitting to tunnels. The next best thing would be to enable
actually using the device layer on tunnels for kernels that support
lightweight tunnels.

I guess both of these are probably disproportionally complicated to
the actual use case here and this isn't a regression, so for the time
being:
Acked-by: Jesse Gross <jesse at kernel.org>



More information about the dev mailing list