On Tue, Feb 16, 2016 at 11:15:20PM +0100, Jiri Benc wrote: > 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.
I was hoping that my idea would work; thanks for saving me the effort of implementing it only to find out that it has the problem you describe. I think that a mode switch is possible, and perhaps it is the best way forwards. But I was hoping to arrange things so that L3 and L2 GRE vports could be used simultaneously, which is why I went for different vport types: unfortunately this complicated the user-space code. At this point I see three options. Jesse, do you have a preference? 1. Use a vport mode for L3 GRE as Jiri suggests. This seems like it may lead to the cleanest implementation. We could later move away from this approach if there is a need for L3 and L2 GRE to co-exist. 2. Add a vport type for L3 GRE as this patch does (or otherwise). This seems a bit more complex than 1, with the caveat that I'm yet to implement 1. But its also more flexible as it allows L3 and L2 GRE to co-exist. 3. Ok, I have no 3rd option other than "something else". > > 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
