On Wed, Dec 07, 2016 at 08:47:56AM +0800, Yang, Yi wrote: > On Tue, Dec 06, 2016 at 09:38:09AM -0500, Eric Garver wrote: > > On Tue, Dec 06, 2016 at 07:17:20AM +0000, Yang, Yi Y wrote: > > > Hi, guys > > > > Hi Yi, > > > > > This patch isn't updated from June on, Cascardo said he/Eric is still > > > working on this, but six months passed, we don't see any following > > > > Work is still ongoing. There was delay due to some debate about how and > > when to prefer out-of-tree vs in-tree tunnels. > > I'd like to know how you will handle 3 cases Pravin mentioned > > """ > Case 1. OVS kernel module is upstream. It is straight forward to > tunnel devices on upstream kernel module. STT and lisp are not > available. > Case 2. OVS kernel module is out of tree. In this case OVS has compat > code and USE_UPSTREAM_TUNNEL is defined. We are using upstream kernel > modules for geneve, gre and vxlan, for rest of vport. (stt and lisp) > we are using netdevices from compat code. > Case 3. OVS kernel module is out of tree and not using upstream tunnel > devices. we have to fallback to OVS compat code for all tunnel > modules. > """ > > According to the below Cascardo's reply, it seems those old patches can > handle all the cases, but my test confirmed we can't create vxlan-gpe if > we don't change the compatibility code, I want to hear your idea about > this. > > """ > So, in summary, we drop this patch, submit what we had before, make sure > it > works in the following scenarions: > > 1) upstream ovs and tunnels are used; > 1a) metadata tunnels can be created, those are used; > 1b) we use compat vports if the configuration allows that; > > 2) out-of-tree ovs and out-of-tree tunnels are used; > we make sure using rtnetlink will fail and compat vport is used; > NOTE: this should work even with the old out-of-tree code that named > drivers as vxlan instead of ovs_vxlan. > > 3) out-of-tree ovs and upstream/in-tree tunnels are used; > it should work just like with upstream ovs, unless the out-of-tree > code does > not support metadata tunnels, in which case, it should fallback to > compat > code. > """ > > > > > > > > > So my advice about this is we can push patch [2] to Linux net-next > > > first, then apply patch series > > > https://mail.openvswitch.org/pipermail/ovs-dev/2016-June/316879.html > > > from Cascardo and apply [1], that can cover all the cases Pravin > > > mentioned. > > > > As Cascardo and Jesse mentioned back in June [1], we should not be > > adding new features to this interface. GPE has been backported to the > > out-of-tree VXLAN code. The only part that remains is userspace changes > > to create with rtnetlink, which is still being worked on. > > I notice if we fallback to ovs compat modules to create vxlan, it will > use generic netlink but not rtnetlink, do you meam you're changing > generic netlink in function dpif_netlink_vport_transact in lib/dpif-netlink.c > to rtnetlink?
If using out-of-tree modules we will try to create using rtnetlink before falling back to genetlink. > I want to know when you have a test patch available, I can help test > even implement it. That would be appreciated. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
