[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