[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