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?
I want to know when you have a test patch available, I can help test
even implement it.
>
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
