[ovs-dev] [PATCH v14 0/7] Add offload support for sFlow

Tue Sep 7 06:02:34 UTC 2021

On 9/7/2021 1:59 PM, Eelco Chaudron wrote:
>
> On 7 Sep 2021, at 3:34, Chris Mi wrote:
>
>> On 9/6/2021 5:47 PM, Eelco Chaudron wrote:
>>> On 6 Sep 2021, at 11:14, Chris Mi wrote:
>>>
>>>> On 9/3/2021 8:54 PM, Eelco Chaudron wrote:
>>>>> On 3 Sep 2021, at 14:02, Eelco Chaudron wrote:
>>>>>
>>>>>       On 15 Jul 2021, at 8:01, Chris Mi wrote:
>>>>>
>>>>>           This patch set adds offload support for sFlow.
>>>>>
>>>>>           Psample is a genetlink channel for packet sampling. TC action
>>>>>           act_sample
>>>>>           uses psample to send sampled packets to userspace.
>>>>>
>>>>>           When offloading sample action to TC, userspace creates a
>>>>>           unique ID to
>>>>>           map sFlow action and tunnel info and passes this ID to kernel
>>>>>           instead
>>>>>           of the sFlow info. psample will send this ID and sampled packet to
>>>>>           userspace. Using the ID, userspace can recover the sFlow info
>>>>>           and send
>>>>>           sampled packet to the right sFlow monitoring host.
>>>>>
>>>>>       Hi Chris,
>>>>>
>>>>>       One thing missing from this patchset is a test case. I think we
>>>>>       should add it, as I’m going over this manually every patch iteration.
>>>>>
>>>>>       I would add the following:
>>>>>
>>>>>        *
>>>>>
>>>>>           Set the sample rate to 1, send 100 packets and make sure you
>>>>>           receive all of them
>>>>>
>>>>>             o Also, verify the output of “ovs-appctl dpctl/dump-flows
>>>>>               system at ovs-system type=tc” is correct, i.e., matches the
>>>>>               kernel output
>>>>>        *
>>>>>
>>>>>           Set the sample rate to 10, send 100 packets and make sure you
>>>>>           receive 10.
>>>>>
>>>>>             o Also, verify the output of “ovs-appctl dpctl/dump-flows
>>>>>               system at ovs-system type=tc” is correct, i.e., matches the
>>>>>               kernel output
>>>>>
>>>>>       Cheers,
>>>>>
>>>>>       Eelco
>>>>>
>>>>>       PS: I also had a problem where only one packet got sent to the
>>>>>       collector, and then no more packets would arrive. Of course, when
>>>>>       I added some debug code, it never happened, and when removing the
>>>>>       debug code, it also worked fine :( Did you ever experience
>>>>>       something like this? I will play a bit more when reviewing
>>>>>       specific code, maybe it will happen again.
>>>>>
>>>>>
>>>>> One additional thing I’m seeing is the following:
>>>>>
>>>>> $ ovs-appctl dpctl/dump-flows system at ovs-system type=tc
>>>>> recirc_id(0),in_port(3),eth(src=52:54:00:88:51:38,dst=04:f4:bc:28:57:01),eth_type(0x0800),ipv4(frag=no), packets:7144, bytes:600096, used:7.430s, actions:sample(sample=10.0%,actions(userspace(pid=3925927229,sFlow(vid=0,pcp=0,output=2147483650),actions))),2
>>>>>
>>>>> Sometimes I get a rather large sFlow(output=) value in the sFlow output. Converting the above to hex, 0x80000002, where I see this in fix_sflow_action() as being mentioned multiple output ports? This seems wrong to me as it should be 3 (as it always is in the none hw offload case). This odd value is also reported to the sFlow samples.
>>>>>
>>>>> Unfortunately, I do not have a reproducer for this.
>>>>>
>>>> Actually, in the very beginning of the development when I have a lot of debug code, I also observed such odd port number sometimes.
>>>> Such rule will disappear soon. So it is hard to test such corner case. And it doesn't affect the functionality.
>>>> So current code didn't deal with such corner case.
>>> I’m getting this almost every time I restart OVS and initiate a flow (using a simple ping). This does not go away by itself, it stays until the flow times out. So this should be investigated and fixed.
>>>
>>> My test setup is rather simple, just two ports, one is a VM one is a external host, which I ping from the VM. All default config, so using the NORMAL rule. This is my sFlow config:
>>>
>>>    ovs-vsctl -- --id=@sflow create sflow agent=lo \
>>>         target="127.0.0.1" header=128 \
>>>         sampling=10 polling=4 \
>>>         -- set bridge ovs_pvp_br0 sflow=@sflow
>>>
>> I tried several times, I can't reproduce it:
>>
>> # ovs-appctl dpctl/dump-flows system at ovs-system type=tc
>> recirc_id(0),in_port(2),eth(src=02:25:d0:09:01:02,dst=02:25:d0:09:01:03),eth_type(0x0800),ipv4(frag=no), packets:10, bytes:840, used:0.050s, actions:sample(sample=10.0%,actions(userspace(pid=3087130156,sFlow(vid=0,pcp=0,output=216),actions))),3
>> recirc_id(0),in_port(2),eth(src=02:25:d0:09:01:02,dst=02:25:d0:09:01:03),eth_type(0x0806), packets:0, bytes:0, used:10.080s, actions:sample(sample=10.0%,actions(userspace(pid=3087130156,sFlow(vid=0,pcp=0,output=216),actions))),3
>> recirc_id(0),in_port(3),eth(src=02:25:d0:09:01:03,dst=02:25:d0:09:01:02),eth_type(0x0800),ipv4(frag=no), packets:10, bytes:840, used:0.050s, actions:sample(sample=10.0%,actions(userspace(pid=3604571673,sFlow(vid=0,pcp=0,output=215),actions))),2
>> recirc_id(0),in_port(3),eth(src=02:25:d0:09:01:03,dst=02:25:d0:09:01:02),eth_type(0x0806), packets:0, bytes:0, used:10.080s, actions:sample(sample=10.0%,actions(userspace(pid=3604571673,sFlow(vid=0,pcp=0,output=215),actions))),2
> Ok, I will try to debug it once I get to reviewing the last patch of the series.
>
Thanks.