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:
>>> >
>>> > filter protocol all pref 1 matchall chain 0
>>> > filter protocol all pref 1 matchall chain 0 handle 0x1
>>> >   in_hw (rule hit 7863)
>>> >         action order 1:  police 0x1 rate 32Mbit burst 1000Kb mtu 64Kb 
>>> > action drop/pipe overhead 0b
>>> >         ref 1 bind 1  installed 17 sec firstused 17 sec
>>> >         Action statistics:
>>> >         Sent 152199634 bytes 102550 pkt (dropped 1315, overlimits 1315 
>>> > requeues 0)
>>> >         Sent software 74612172 bytes 51275 pkt
>>> >         Sent hardware 77587462 bytes 51275 pkt
>>> >         backlog 0b 0p requeues 0
>>> >         used_hw_stats delayed
>>> >
>>> > filter protocol ip pref 3 flower chain 0
>>> > filter protocol ip pref 3 flower chain 0 handle 0x1
>>> >   dst_mac aa:94:1f:f2:f8:44
>>> >   src_mac e4:00:01:08:00:02
>>> >   eth_type ipv4
>>> >   ip_flags nofrag
>>> >   not_in_hw
>>> >         action order 1: skbedit  ptype host pipe
>>> >          index 1 ref 1 bind 1 installed 6 sec used 6 sec
>>> >         Action statistics:
>>> >         Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>>> >         backlog 0b 0p requeues 0
>>> >
>>> >         action order 2: mirred (Ingress Redirect to device br-ovs) stolen
>>> >         index 1 ref 1 bind 1 installed 6 sec used 6 sec
>>> >         Action statistics:
>>> >         Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>>> >         backlog 0b 0p requeues 0
>>> >         cookie 401a9c8b3d403c62240d3eb5e21c1604
>>> >         no_percpu
>>> >
>>> > Fix the issue by restoring pps policer action type to 'continue'.
>>> >
>>> > Fixes: c2567e533f8a ("add port-based ingress policing based 
>>> > packet-per-second rate-limiting")
>>> > Signed-off-by: Vlad Buslov <vla...@nvidia.com>
>>> 
>>> Review-by: Marcelo Ricardo Leitner <mleit...@redhat.com>
>>
>> Thanks,
>>
>> talking with the team at Corigine I believe we do have some use cases
>> around metering that depend on TC_ACT_PIPE and we're trying to evaluate
>> how this patch might affect them. I'd appreciate it if we could have
>> a little more time to complete that evaluation.

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.

Thanks
Vlad

>>
>> Thanks in advance,
>> Simon
>
> Note that I didn't change the use-case you added. It still uses PIPE
> with my patch.
>
> Regards,
> Vlad

_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to