On Tue, Aug 02, 2022 at 10:38:03AM +0300, Vlad Buslov wrote: > On Wed 27 Jul 2022 at 11:49, Vlad Buslov <vla...@nvidia.com> wrote: > > On Wed 27 Jul 2022 at 10:26, Simon Horman <simon.hor...@corigine.com> wrote: > >> On Tue, Jul 26, 2022 at 07:52:31AM -0500, Marcelo Ricardo Leitner wrote: > >>> On Tue, Jul 26, 2022 at 09:24:12AM +0200, Vlad Buslov wrote: > >>> > Referenced commit changed policer action type from TC_ACT_UNSPEC > >>> > (continue) to TC_ACT_PIPE. However, since neither TC hardware > >>> > offload layer nor mlx5 driver at the time validated action type and > >>> > always assumed 'continue', the breakage wasn't caught until later > >>> > validation code was added. The change also broke valid > >>> > configuration when sending from offload-capable device to > >>> > non-offload capable. For example, when sending from mlx5 VF to OvS > >>> > bridge netdevice the traffic that passed matchall classifier with > >>> > policer could no longer match the following flower rule in > >>> > software:
... > Hi Simon, > > Any updates on this? I'm asking because 5.19 has been released and we > would like to restore port rate limiting offload support with upstream > OvS. Hi Vlad, I apologise for the delay in responding, and in turn that our investigation took a little longer than it might have. Firstly, regarding BPS (byte/bit per-second) and PPS (packet per-second) rate limits. It turns out that the need for TC_ACT_PIPE is unrelated to BPS/PPS. And it was only included in the patch that introduced PPS rate limiting as an artifact of the development process. Sorry about that. Secondly, with the introduction of metering the TC_ACT_PIPE behaviour came to be relied on for some use cases. And unfortunately, because these case can use either BPS or PPS the proposed patch causes a regression. The example I have is when a mirred action follows a meter. It is not strictly related to conntrack (CT) but it is convenient for us to illustrate the problem with an example that includes CT. Suppose that part of the OVS flow table looks like this: table=0,in_port=eth6,ct_state=-trk,ip,actions=ct(table=1) table=1,in_port=eth6,ct_state=+trk+new,ip,actions=ct(commit),output:eth5 table=1,in_port=eth6,ct_state=+trk+est,ip,actions=meter:1,output:eth5 And one of the corresponding TC rules is as follows: filter protocol ip pref 2 flower chain 1 filter protocol ip pref 2 flower chain 1 handle 0x2 eth_type ipv4 ip_flags nofrag ct_state +trk+est in_hw in_hw_count 1 action order 1: police 0x10000000 rate 4Gbit burst 125000Kb mtu 64Kb action drop/continue overhead 0b linklayer unspec ref 41 bind 40 installed 18 sec firstused 15 sec Action statistics: Sent 6876408827 bytes 4658827 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 used_hw_stats delayed action order 2: mirred (Egress Redirect to device eth5) stolen index 3 ref 1 bind 1 installed 15 sec used 15 sec Action statistics: Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 cookie 20bea269bf40fdf3893eccbc6a7a07d8 no_percpu used_hw_stats delayed In this case, if the under-limit action for the policer action is TC_ACT_PIPE then things work as expected (the packet is output to eth5 if the rate is not exceeded). However, if the under-limit action for the policer action is TC_ACT_UNSPEC, as in the example above, the mirred action is never hit and packets are not output to eth5, regardless if the reate is exceded or not. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev