[ovs-dev] [PATCH v9 7/7] userspace: add non-tap (l3) support to GRE vports

Jesse Gross jesse at kernel.org
Wed Jan 27 06:09:28 UTC 2016


On Tue, Jan 19, 2016 at 10:15 PM, Simon Horman
<simon.horman at netronome.com> wrote:
> Add support for layer 3 GRE vports (non-tap aka non-VTEP).
>
> This makes use of a separate vport type for GRE, rather than a new mode for
> the existing (tap/VTEP) GRE vports as this fits more naturally with the
> kernel where implementation of GRE and thus implementation of this feature
> there.
>
> In order to differentiate packets for two different types of GRE vports a
> new flow key attribute, OVS_KEY_ATTR_NEXT_BASE_LAYER, is used.  It is
> intended that this attribute is only used in userspace as there appears to
> be no need for it to be used in the kernel datapath.
>
> It is envisaged that this attribute may be used for other non-UDP
> encapsulation protocols that support both layer3 and layer2 inner-packets.
> While for UDP encapsulation the UDP port can be used for differentiation
> without the need for this new attribute.
>
> One alternative approach to this new attribute, which I have not
> investigated in detail, would be to use a second classifier in tnl-ports.c
> for non-UDP layer3 tunnels; leaving the existing classifier for all other
> tunnels.
>
> Signed-off-by: Simon Horman <simon.horman at netronome.com>

I think it's likely that we'll have a variety of tunnels in the near
future that can natively support multiple inner frame formats without
changing the encapsulation type. This is somewhat different from what
we have now where although different tunnels support various frame
formats, there is primarily a 1:1 mapping of encapsulation:inner frame
(such as with VXLAN, LISP, and STT). Protocols that fall into this
category include GRE (Ethernet/IPv4/IPv6/MPLS), Geneve, and VXLAN-GPE
(NSH).

It seems like it would be ideal if we can avoid creating a new port
type for each of these possible combinations and somehow just make the
flow keys look right. After all, in the case of GRE, we already
support all of the inner protocols that I mentioned about through the
main flow lookup so it would be cool if after decapsulation the
appropriate packet came out with the addition of GRE metadata.

One other comment - in the case of UDP based protocols I don't think
that it is likely that different UDP ports will be used to indicated
different inner protocols. This shouldn't be necessary for protocols
that have a next protocol field and I don't think the people would be
excited about changing the port in that case.



More information about the dev mailing list