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

Simon Horman simon.horman at netronome.com
Mon Feb 1 16:05:18 UTC 2016


On Tue, Jan 26, 2016 at 10:09:28PM -0800, Jesse Gross wrote:
> 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.

I think that sounds reasonable. But I am wondering if you have any thoughts
on how this might be implemented.

The once approach that I have considered so far would be to rework of
kernel's GRE code to allow it to provide a netdev that can handle both tap
and non-tap (l2 and l3 payloads). I can investigate this more closely if
you think it is an approach worth pursuing.

> 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.

Understood.



More information about the dev mailing list