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.hor...@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.hor...@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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
