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? > >> > >> Can you take a look at these and also maybe do some more testing in > >> these types of edge scenarios? > > > > I will. On the previous version, I remember testing an upgrade from OVS > > without > > the patch to OVS with the patch. I will look into those issues and test > > both a > > restart and an upgrade scenario on some different kernels. > > 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. The other advantage is that openvswitch does not need to care about the netlink ABI/protocol for those features anymore. Just leave it to the drivers. The disadvantages are: 1) Supporting two different methods, not sure if that's too much of a work. 2) Not supporting some features on some kernels; that's going to happen anyway. 3) Relying on someone else's rtnetlink ABI, ie, the drivers'. OVS already relies on them somehow and we all have an eye on them, doing backports, and testing them. 4) Lack of atomicity when adding/removing ports. It may be the cause for the problem above. Should we fix it by adding a flag to the OVS_VPORT_CMD_DEL command? This would only fix it for some kernels. Cascardo. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
