On Thu, May 18, 2017 at 03:35:34PM -0700, Greg Rose wrote: > On Thu, 2017-05-18 at 16:10 -0400, Eric Garver 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. > > > > Note: This work originally started by Thadeu Lima de Souza Cascardo. > > > > Note: There is a known failure for GENEVE tunnels using rtnetlink on newer > > kernels. This is being addressed with a separate kernel fix. The fallback to > > compat will work however. > > I've applied these patches for testing and review and I get these errors > when I run make check on a 4.12-rc1 kernel: > 783: tunnel-push-pop.at:3 tunnel_push_pop - action > 784: tunnel-push-pop.at:191 tunnel_push_pop - packet_out > 785: tunnel-push-pop.at:229 tunnel_push_pop - underlay bridge match > 786: tunnel-push-pop-ipv6.at:3 tunnel_push_pop_ipv6 - action > > Are these the known failures? Was there something in the compat that > needs fixing? I'm sort of new to this so please excuse any obvious > ignorance showing.
Not known. Some of the tests aren't the most reliable. I usually run with RECHECK=yes. Here are the travis-ci results for this series (no failures): https://travis-ci.org/erig0/ovs/builds/233759266 > > I've downloaded the 4.9.23 kernel and will try against that next. Thanks for testing! > > Thanks, > > - Greg > > > > > Testing: > > - kernel 4.9.22, in-tree datapath > > - rtnetlink successfully creates devices > > - kernel 4.2.8, in-tree datapath > > - rtnetlink is tried, but fails due to no COLLECT_METADATA support > > - genetlink successfully creates devices > > - kernel 4.2.8, out-of-tree datapath > > - rtnetlink is not tried > > - genetlink successfully creates devices > > - Create a native VXLAN interface with incorrect config, run VXLAN > > check-kernel test. Old device is replaced by OVS created one. > > > > v5: > > - Make dpif_netlink_rtnl_port_create() easier to follow. > > - Reword some patch descriptions > > > > v4: > > - If device exists, verify and potentially delete/re-add. This handles the > > case where OVS may be killed. > > - Further commonize rtnetlink code; create, verify, delete > > - Incorporate Joe's style changes from last review > > > > v3: > > - commonzie code to get port data to verify port > > - eliminate dpif_netlink_rtnl_vxlan_destroy() and alike > > - minor changes for coding style guidelines > > - add ACKs from previous reviews > > > > Eric Garver (6): > > dpif-netlink: Refactor code to create compat ports > > dpif-netlink: Support rtnetlink port creation. > > dpif-netlink-rtnl: Support VXLAN creation > > dpif-netlink-rtnl: Support GRE creation > > dpif-netlink-rtnl: Support GENEVE creation > > dpif-netlink: Probe for out-of-tree tunnels, decides used interface > > > > Thadeu Lima de Souza Cascardo (1): > > netdev: get device type from vport prefix if it uses one > > > > NEWS | 3 + > > lib/automake.mk | 3 + > > lib/dpif-netlink-rtnl.c | 467 > > ++++++++++++++++++++++++++++++++++++++++++++++++ > > lib/dpif-netlink-rtnl.h | 54 ++++++ > > lib/dpif-netlink.c | 210 ++++++++++++++-------- > > lib/dpif-netlink.h | 2 + > > lib/netdev.c | 26 ++- > > 7 files changed, 691 insertions(+), 74 deletions(-) > > create mode 100644 lib/dpif-netlink-rtnl.c > > create mode 100644 lib/dpif-netlink-rtnl.h > > > > > > _______________________________________________ > dev mailing list > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
