On Wed, Jun 22, 2016 at 8:47 AM, Thadeu Lima de Souza Cascardo <casca...@redhat.com> wrote: > This series adds support for the creation of tunnels using the rtnetlink > interface. This will open the possibility for new features and flags on those > vports without the need to change vport compatibility code. > > Support for STT and LISP have not been added because these are not upstream > yet, > so we don't know how the interface will be like upstream. And there are no > features in the current drivers right now we could make use of.
I noticed some interesting test failures while looking at this series. Some of them are existing but they appear to be related to the earlier conversation that we had with the tunnel routing code. The background is that I normally run unit tests on my development machine and real tests with traffic on a different machine. In that case the problem does not appear. The issue came up when I happened to run the unit tests on a machine with a running configuration of OVS. In that case, it seems that something picks up the existing tunnel kernel netdev, opens it, and then uses that for the unit tests (which should be purely in userspace and theoretically not affected). Here is what I get in the above scenario (some other related tests appear to fail intermittently as well): tunnel_push_pop 750: tunnel_push_pop - action FAILED (tunnel-push-pop.at:154) 751: tunnel_push_pop - packet_out FAILED (tunnel-push-pop.at:201) tunnel_push_pop_ipv6 752: tunnel_push_pop_ipv6 - action FAILED (tunnel-push-pop-ipv6.at:149) This is presumably caused by the wrong type being used. Wouldn't problems like this be avoided by using the other mechanism that you proposed, whereby we identify the type on netdev_open() and use that? I guess it doesn't seem like that big of a change to me and looks to be more robust (or at least easier to diagnose if things go wrong). The other area that we talked about before is how to handle backports in the kernel modules with this new mechanism. I'm not sure that this has been resolved. Do you have any more thoughts? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
