[ovs-dev] [RFC PATCH] datapath: allow tunnels to be created with rtnetlink

Eric Garver e at erig.me
Thu Dec 8 20:24:35 UTC 2016


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.


More information about the dev mailing list