On 6 Sep 2021, at 10:45, Chris Mi wrote:
> Hi Eelco, > > On 9/3/2021 8:02 PM, 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. >> > Sure. I'll check existing test cases and see how to add them. >> >> 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@ovs-system type=tc” is correct, i.e., matches the >> kernel output >> > OK. >> >> * >> * >> >> Set the sample rate to 10, send 100 packets and make sure you >> receive 10. >> > We have some internal ovs test cases to verify sFlow offload. From our > experience, > we can't verify sFlow easily using so less packets. We send a lot of traffic > in a certain > period and verify the packet number is between a range. Ok, did not try high-speed tests but for me doing “ping 1.1.1.100 -c 100 -i 0.01” seems rather ok. I miss 1, which I guess, is based on some other traffic that might have occurred, affecting the stats. But as you suggest adding a range will do. > BTW, I'm not sure if you are aware of that our driver change for sFlow > offload is upstreamed. > The main change is in file: > drivers/net/ethernet/mellanox/mlx5/core/en/tc/sample.c . No, I have not tracked the upstream net-specific changes. I might try it out later on in the test. >> * >> o Also, verify the output of “ovs-appctl dpctl/dump-flows >> system@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. >> > Are you testing with other_config:hw-offload="true" and > other_config:tc-policy=skip_hw? I’m using the default policy, none, but without a HW offload blade. > Actually, our internal test cases have been running for a long time. We > haven't found such issue yet :) > Anyway, I'll pay attention to this issue to see if I can reproduce it. Thanks, will try to replicate this. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
