Hi Neil, Seems that's a possible fix because in most case, there might not be mixed tunnel types, set tunnel type to unknown will not affect analysis much.
However, seems this patch is also present on master branch, I am wondering the stability and test coverity of sFlow feature of OVS. Since we are evaluating using sFlow as a network monitoring in our cloud, do you have any advice about the using that feature with OVS? 2016-08-26 18:08 GMT+08:00 Neil McKee <neil.mc...@inmon.com>: > I think it would be OK to do this: > > tnlInProto = in_dsp ? dpif_sflow_tunnel_proto(in_dsp->tunnel_type) : 0; > > Neil > > > ------ > Neil McKee > InMon Corp. > http://www.inmon.com > > On Fri, Aug 26, 2016 at 2:30 AM, 张东亚 <fortitude.zh...@gmail.com> wrote: > >> Hi List, >> >> Recently we are testing sFlow on OVS 2.5.0, since OVS decide whether do >> sample based on ingress bridge, we then enable sFlow on br-tun, and >> encounter following crash: >> >> #0 0x0000000000434ca8 in dpif_sflow_received (ds=0x4266100, >> packet=packet@entry=0x7f3cb3fc8e18, flow=flow@entry=0x7f3cb3fd8810, >> odp_in_port=<optimized out>, cookie=cookie@entry=0x7f3cb3fc3440, >> sflow_actions=0x7f3cb3fc36c0) at ofproto/ofproto-dpif-sflow.c:1292 >> #1 0x00000000004366c0 in process_upcall (udpif=udpif@entry=0x23bb570, >> upcall=upcall@entry=0x7f3cb3fe1210, >> odp_actions=odp_actions@entry=0x7f3cb3fe1280, >> wc=wc@entry=0x7f3cb3fe12c0) >> at ofproto/ofproto-dpif-upcall.c:1236 >> #2 0x0000000000437087 in recv_upcalls (handler=<error reading variable: >> Unhandled dwarf expression opcode 0xfa>, handler=<error reading variable: >> Unhandled dwarf expression opcode 0xfa>) >> at ofproto/ofproto-dpif-upcall.c:778 >> #3 0x000000000043752a in udpif_upcall_handler (arg=0x24a3490) at >> ofproto/ofproto-dpif-upcall.c:696 >> #4 0x00000000004bbc54 in ovsthread_wrapper (aux_=<optimized out>) at >> lib/ovs-thread.c:340 >> #5 0x00007f3cb9f96e0e in start_thread () from >> /lib/x86_64-linux-gnu/libpthread.so.0 >> #6 0x00007f3cba2940fd in clone () from /lib/x86_64-linux-gnu/libc.so.6 >> >> >> After navigate the code, we think the following commit cause the crash: >> >> 7321bda384c366ae36bbca445f235a65d8f2b1f8 >> >> Extend sFlow agent to report tunnel and MPLS structures >> >> It seems that in the following code assume in vsp have a value, however >> for tunnel port, in vsp will always be NULL since there is only on >> vxlan_sys_4789 datapath port. >> >> >> if (flow->tunnel.ip_dst) { >> memset(&tnlInElem, 0, sizeof(tnlInElem)); >> tnlInElem.tag = SFLFLOW_EX_IPV4_TUNNEL_INGRESS; >> tnlInProto = dpif_sflow_tunnel_proto(in_dsp->tunnel_type); // BUG: >> in_dsp will be NULL... >> dpif_sflow_tunnel_v4(tnlInProto, >> &flow->tunnel, >> &tnlInElem.flowType.ipv4); >> SFLADD_ELEMENT(&fs, &tnlInElem); >> if (flow->tunnel.tun_id) { >> memset(&vniInElem, 0, sizeof(vniInElem)); >> vniInElem.tag = SFLFLOW_EX_VNI_INGRESS; >> vniInElem.flowType.tunnel_vni.vni >> = ntohll(flow->tunnel.tun_id); >> SFLADD_ELEMENT(&fs, &vniInElem); >> } >> } >> >> Does anyone encounter the same value? I am wondering how we can get >> tunnel types from the datapath information. >> >> I will try to find a fix later. >> >> _______________________________________________ >> discuss mailing list >> discuss@openvswitch.org >> http://openvswitch.org/mailman/listinfo/discuss >> >> >
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
