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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
