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

Eelco Chaudron echaudro at redhat.com
Fri Sep 3 12:54:45 UTC 2021



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
>    - 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.
>    - 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.

//Eelco



More information about the dev mailing list