Sorry for the late answer, was busy with a conference and internal meetings in the past two weeks.
On Tue, 2 Feb 2016 17:15:15 -0800, Jesse Gross wrote: > I think this sounds like a good idea if we can find a way to do it > cleanly. From OVS's perspective, the main thing that we need is a way > to indicate the first header that we expect to see. We used to have > this in struct tnl_ptk_info proto but that is no longer exposed to > OVS. We also want to make sure that a device that is configured in > this mode behaves in a logical way when not connected to OVS - i.e. it > knows whether to emit ARP for L2 ports but not L3. I suppose now that > lightweight tunneling is here both interfaces are common and therefore > the problem is the same in each case, which is a good thing. There's only one way to solve this cleanly in the kernel. The L2 vs. L3 mode has to be selected while creating the tunnel interface and cannot be changed afterwards (only by deleting and recreating the interface). The reason is that the L3 interface needs to be of ARHRD_NONE type instead of ARPHRD_ETHER. With additional flags set by the kernel (IFF_NOARP in particular), this works as expected out of ovs, e.g. for route based encapsulation. It's not possible to mix those two in a single interface. E.g. for VXLAN-GPE, it's either Ethernet header is encapsulated or not for a given interface (and thus for a given vport), and never both. If we did that, such interface wouldn't work standalone, outside of ovs. I don't think it's a problem. The information whether Ethernet header info is provided in the flow key or not can be directly deduced from the net_device type. It's quite generic this way: if it's ARPHRD_ETHER, there's Ethernet header, if it's ARPHRD_NONE, no L2 header is available. In the future, it's easy to add different L2 transports if desired in the same way. The user has to request the L2 or L3 mode when creating the VXLAN-GPE interface. This will be the same for L3 Geneve, and likely for GRE, too (I'll have to check the current implementation of that one). So yes, we'll need a way to distinguish this when creating the vport. Either a new vport type, or an L3 flag. It makes sense, actually: the vports are very different, e.g. different flow rules are needed for L2 and L3 tunnels (for L3, push_eth when switching to Ethernet will be needed to be configured at least). Of course, currently, the kernel datapath allows only ARPHRD_ETHER interfaces to be added to the ovs bridge and this will need to be changed. > Jiri (cc'ed) is working on GPE and NSH support to VXLAN at the moment. > I think this is very closely related and complementary as it also > depends on sending non-Ethernet frames to OVS. He might have some > ideas on how to handle this. Jiri -- Jiri Benc _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
