Hi Neil, There is another question regarding the issue, seems dpif_sflow_add_port will call dpif_sflow_del_port port every time, does this is intended to remove previously added dsp since dp_port might be same for different tunnel port?
2016-08-29 11:16 GMT+08:00 张东亚 <fortitude.zh...@gmail.com>: > 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
