Hi Jamal,
When no action is specified, there should not be gact with PIPE, rather than a
gact with drop, like:
`
# tc -s -d filter show dev eth8 ingress
filter protocol ipv6 pref 3 flower chain 0
filter protocol ipv6 pref 3 flower chain 0 handle 0x1
eth_type ipv6
ip_flags nofrag
in_hw in_hw_count 1
action order 1: gact action drop
random type none pass val 0
index 1 ref 1 bind 1 installed 315 sec used 67 sec
Action statistics:
Sent 1412 bytes 18 pkt (dropped 18, overlimits 0 requeues 0)
Sent software 0 bytes 0 pkt
Sent hardware 1412 bytes 18 pkt
backlog 0b 0p requeues 0
cookie 54ed8ed8714cc38e7a7abc9009199520
no_percpu
used_hw_stats delayed
`
Also attach the info about dumping a filter, in which there is a PIPE before
POLICE:
`
[root@compute1 ovs-private]# tc -s -d filter show dev eth5 ingress
filter protocol ip pref 2 flower chain 0
filter protocol ip pref 2 flower chain 0 handle 0x1
eth_type ipv4
ip_flags nofrag
in_hw in_hw_count 1
action order 1: gact action pipe
random type none pass val 0
index 1508263657 ref 1 bind 1 installed 87 sec used 0 sec
Action statistics:
Sent 1422020 bytes 20648 pkt (dropped 0, overlimits 0 requeues 0)
Sent software 0 bytes 0 pkt
Sent hardware 1422020 bytes 20648 pkt
backlog 0b 0p requeues 0
no_percpu
used_hw_stats delayed
action order 2: police 0x10000000 rate 30Mbit burst 1250Kb mtu 64Kb
action drop/pipe overhead 0b linklayer unspec
ref 4 bind 3 installed 121 sec used 0 sec firstused 120 sec
Action statistics:
Sent 333966615 bytes 239585 pkt (dropped 0, overlimits 0 requeues 0)
Sent software 696 bytes 12 pkt
Sent hardware 333965919 bytes 239573 pkt
backlog 0b 0p requeues 0
used_hw_stats delayed
action order 3: mirred (Egress Redirect to device eth6) stolen
index 8 ref 1 bind 1 installed 87 sec used 0 sec
Action statistics:
Sent 1422020 bytes 20648 pkt (dropped 0, overlimits 0 requeues 0)
Sent software 0 bytes 0 pkt
Sent hardware 1422020 bytes 20648 pkt
backlog 0b 0p requeues 0
cookie e946e659084028456b360ab443f77cd0
no_percpu
used_hw_stats delayed
`
About the second scenario of PIPE alone, I don’t think it should exist.
Besides this adding a PIPE at the first place of a tc filter to update the flow
stats, another
attempt that directly store the flower stats, which is got from driver, in
socket transacted
with userspace (e.g. OVS). In this approach, we don’t have to make changes in
driver. Which
could be a better solution you think for this propose
cheers,
Tianyu
On Sat, Nov 26, 2022 at 12:54 AM Jamal Hadi Salim
<[email protected]<mailto:[email protected]>> wrote:
Hi Tianyu,
On Thu, Nov 24, 2022 at 10:10 PM Tianyu Yuan
<[email protected]<mailto:[email protected]>> wrote:
On Fri, Nov 25, 2022 at 10:21 AM Jamal Hadi Salim
<[email protected]<mailto:[email protected]>> wrote:
>
> I am not sure if the mlx5 changes will work since they both seem to be
> calling
> mlx5e_tc_act_get() which expects the act->id to exist in tc_acts_xxx tables,
> meaning mlx5e_tc_act_get() will always return you NULL and that check is
> hit before you check for ACT_PIPE.
[..]
>
Thanks Jamal for your review.
About mlx5e_tc_act_get(), I'll later add PIPE action in tc_acts_nic so that
mlx5e_tc_act_get() will return the right
act_id.
Just noticed Vlad posted a patch for it ;->
I only looked at that change because i have that hardware and wanted to try it
out.
You are Ccing all the driver stakeholders hopefully they can double check.
In driver we choose just ignore this gact with ACT_PIPE, so after parsing the
filter(rule) from kernel, the remaining
actions are just like what they used to be without changes in this patch. So
the flow could be processed as before.
So in the simple case it is as if no action was specified?
The connection between POLICE and ACT_PIPE may exist in userspace (e.g. ovs),
we could put a gact (PIPE) at the
beginning place in each tc filter. We will also have an OVS patch for this
propose.
makes sense.
I'm not very clear with your last case, but in expectation, the once the
traffic is offloaded in h/w tc datapath, the
stats will be updated by the flower stats from hardware. And when the traffic
is using s/w tc datapath, the stats are
from software.
My initial thought was you want to cover two scenarios:
1) pipe followed by police.
2) pipe alone
In both cases pipe serves as a placeholder for stats counters. That these
counters
come from hardware and will occasionally be updated to tc by the driver.
i.e if i get/dump the filter or pipe action stats i can see the hw count. Am i
correct? If the
answer is yes, then would i see the hw stats and not the sw stat updates?
Maybe if you have a filter dump in your test environment that you can show it
will
help satisfy my curiosity.
cheers,
jamal
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
