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

Reply via email to