On Fri, Jun 10, 2016 at 12:04 PM, Thadeu Lima de Souza Cascardo <casca...@redhat.com> wrote: > On Fri, Jun 10, 2016 at 09:11:39AM -0700, Jesse Gross wrote: > [...] >> 2016-06-10T03:53:14.768Z|00034|dpif|WARN|system@ovs-system: failed to >> add tun0 as port: File exists >> [...] >> >> tun0 is type GRE, so gre_sys is it's backing port. >> > > Hum, OK. That explains it. But it should have been removed when OVS started, > if > it was part of the datapath. If it wasn't part of the datapath, that would > explain it. Those cases are not handled by current code either. But maybe my > code makes this a more likely scenario. What if OVS is killed between removing > the port from the datapath and deleting the interface?
Unfortunately, I haven't been able to reproduce this problem (the other one which occurs when killing and restarting OVS is 100% reliable). As far as the situation where there is an existing device that is floating out there and is unattached to a datapath, it would certainly be nice to reclaim it if it is useable - that would make the behavior more robust and similar to what happens today. >> One area that also came to mind is how changes to tunnel protocols in >> the backported module of OVS should be handled. Currently, this code >> will never pick them up - it will just fall back to the compatibility >> layer. (This isn't an issue right now but imagine a new feature that >> gets added upstream - such as VXLAN-GPE - there won't be any way to >> access it on older kernels.) > > Well, I thought that was the point of marking vport-$TUNNEL as compatibility > code. If we are not going to add those features to those modules, we need to > support them somehow, which is the reason for this patchset. Otherwise, maybe > we > should just drop my patchset and start adding these new features to vport > modules. > > One of the advantages of having these features in userspace is that we don't > depend on the features being available on the kernel. At least not in the > openvswitch side, only the drivers side. And if we depend on those features > being available in the drivers anyway, and driver backports are done in OVS > tree, there is no advantage in adding those to openvswitch kernel side. I'm not proposing that we start adding new functionality to the vport tunnel modules. I think it's clear that those are pure compatibility. However, we do need a clean mechanism to distribute backported functionality from the tunnel drivers as part of OVS. A significant chunk of users are using the out of tree backports bundled with OVS and are looking for newer protocols, etc. than come with the kernel they are using. (For example, OVN needs Geneve which isn't available on 3.10 series kernels.) We already have this code backported in the OVS tree - not as part of the vport drivers but as largely independent components that mirror the upstream versions. However, this new userspace code won't take advantage of them at the moment. The reason why it won't work currently is because the OVS backports register themselves as "ovs_" + the original type. This is to avoid colliding with other uses of the upstream modules. I can think of two possible solutions: * Have userspace try to find and create the OVS versions first (although taking care to make sure that we don't use them accidentally on kernels that don't support lightweight tunnels since they won't work in that situation and we should use the old compat interface to create them *but* we still need to send any new feature commands directly to the device). * Find a way to handle more of this transparently in the kernel. The driver modules will need to work reasonably independently of OVS and then can expose the exact same netlink names. On older kernels we'll still need a private way of exchanging packets between OVS and tunnel drivers since the LWT metadata won't make it through the stack. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
