[ovs-dev] [PATCH v14 0/7] Add offload support for sFlow
Chris Mi
cmi at nvidia.com
Wed Sep 8 11:52:50 UTC 2021
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
>
When writing the test, I can reproduce it. Not sure what changed. But it
happens even without offload. I don't know what need to be fixed.
OVS generates the DP rule and installs it. If offload is enabled,
sFlow(vid=0,pcp=0,output=2147483650) (actually the whole action) is saved in
dpif_sflow_attr->action when installing the DP rule. When receiving
sampled packets, tc or driver passes the gid to ovs daemon and
the daemon will find the dpif_sflow_attr->action using the gid. TC
didn't change it. It is up to OVS sflow engine to process it.
More information about the dev
mailing list