On 1 December 2015 at 19:06, Pravin Shelar <pshe...@nicira.com> wrote: > On Mon, Nov 30, 2015 at 5:44 PM, Joe Stringer <joestringe...@gmail.com> wrote: >> On 25 November 2015 at 21:25, Pravin B Shelar <pshe...@nicira.com> wrote: >>> Following patch adds support for lwtunnel to OVS datapath. >>> With this change OVS datapath detect lwtunnel support and >>> make use of new APIs if available. On older kernel where the >>> support is not there the backported tunnel modules are used. >>> These backported tunnel devices acts as lwtunnel devices. >>> I tried to keep backported module same as upstream for easier >>> bug-fix backport. Since STT and LISP are not upstream OVS >>> always needs to use respective modules from tunnel compat layer. >>> To make it work on kernel 4.3 I have converted STT and LISP >>> modules to lwtunnel API model. >>> >>> lwtunnel make use of skb-dst to pass tunnel information to the >>> tunnel module. On older kernel this is not possible. So the in >>> case of old kernel metadata ref is stored in OVS_CB and direct >>> call to tunnel transmit function is made by respective tunnel >>> vport modules. Similarly on receive side tunnel recv directly >>> call netdev-vport-receive to pass the skb to OVS. >>> >>> Major backported components include: >>> Geneve, GRE, VXLAN, ip_tunnel, udp-tunnels GRO. >>> >>> Signed-off-by: Pravin B Shelar <pshe...@nicira.com> >> >> Hi Pravin, >> >> I'm actually seeing ubuntu kernels 3.13-4.2 becoming very unhappy with >> this patch when sending traffic through a vxlan tunnel with one >> endpoint in OVS in the host kernel, then the other vxlan endpoint as a >> native linux vxlan device sitting inside a namespace. This is >> something that works fine on master, and I think it was fine on >> earlier versions of the patch before the flow's actions were being >> freed (the fix for that revealed this problem). >> >> This test can be found by installing a recent iputils (for vxlan >> device creation via `ip link'), installing the module with this patch >> applied, and running `make check-kmod TESTSUITEFLAGS="-k vxlan"'. In >> practice I think that the minimal reproduction is as simple as adding >> a vxlan port to OVS when using a kernel < 4.3. >> >> I've got some example output below, but the actual errors vary quite a >> lot. Can you confirm whether you see the same sorts of problems? >> >> [ 145.711581] netconsole: network logging started >> [ 145.735192] nf_conntrack version 0.5.0 (16384 buckets, 65536 max) >> [ 148.156410] openvswitch: module verification failed: signature >> and/or required key missing - tainting kernel >> [ 148.158596] openvswitch: Open vSwitch switching datapath 2.4.90 >> [ 148.159501] openvswitch: LISP tunneling driver >> [ 148.159543] openvswitch: GRE over IPv4 tunneling driver >> [ 148.159577] openvswitch: Geneve tunneling driver >> [ 148.159676] openvswitch: VxLAN tunneling driver >> [ 148.159702] openvswitch: STT tunneling driver >> [ 150.980949] device ovs-system entered promiscuous mode >> [ 151.004448] device br0 entered promiscuous mode >> [ 151.042316] device br-underlay entered promiscuous mode >> [ 151.136654] IPv6: ADDRCONF(NETDEV_UP): ovs-p0: link is not ready >> [ 151.172313] device ovs-p0 entered promiscuous mode >> [ 151.203725] IPv6: ADDRCONF(NETDEV_CHANGE): ovs-p0: link becomes ready >> [ 151.228493] device vxlan_sys_4789 entered promiscuous mode >> [ 151.265848] general protection fault: 0000 [#1] SMP >> [ 151.265898] Modules linked in: veth vport_vxlan(OX) openvswitch(OX) > > Thanks for the bug report. We need to define dst_release for compat > kernel to free compat metadata_dst. I have incorporated fix in the > updated patch.
Thanks for the update. I'll do a fresh set of testing in the morning and send an updated version of the conntrack backport. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
