[ovs-dev] [PATCH v2 0/5] create tunnel devices using rtnetlink interface

[Thadeu Lima de Souza Cascardo]

On Fri, Jun 10, 2016 at 09:11:39AM -0700, Jesse Gross wrote:
[...]
> 2016-06-10T03:53:14.768Z|00034|dpif|WARN|system at 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.