From: Tonghao Zhang <redacted>
We look up and then check tc_skip_classify flag in net
sched layer, even though skb don't want to be classified.
That case may consume a lot of cpu cycles.
Install the rules as below:
$ for id in $(seq 1 100); do
$ tc filter add ... egress prio $id ... action mirred egress redirect dev ifb0
$ done
netperf:
$ taskset -c 1 netperf -t TCP_RR -H ip -- -r 32,32
$ taskset -c 1 netperf -t TCP_STREAM -H ip -- -m 32
Without this patch:
10662.33 tps
108.95 Mbit/s
With this patch:
12434.48 tps
145.89 Mbit/s
For TCP_RR, there are 16.6% improvement, TCP_STREAM 33.9%.
Cc: Willem de Bruijn <willemb@google.com>
Cc: Cong Wang <redacted>
Cc: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Tonghao Zhang <redacted>
---
net/core/dev.c | 3 ++-
net/sched/act_api.c | 3 ---
2 files changed, 2 insertions(+), 4 deletions(-)
From: Daniel Borkmann <daniel@iogearbox.net> Date: 2021-10-28 14:28:23
On 10/28/21 3:56 PM, xiangxia.m.yue@gmail.com wrote:
From: Tonghao Zhang <redacted>
We look up and then check tc_skip_classify flag in net
sched layer, even though skb don't want to be classified.
That case may consume a lot of cpu cycles.
Install the rules as below:
$ for id in $(seq 1 100); do
$ tc filter add ... egress prio $id ... action mirred egress redirect dev ifb0
$ done
Do you actually have such a case in practice or is this just hypothetical?
Asking as this feels rather broken to begin with.
quoted hunk
netperf:
$ taskset -c 1 netperf -t TCP_RR -H ip -- -r 32,32
$ taskset -c 1 netperf -t TCP_STREAM -H ip -- -m 32
Without this patch:
10662.33 tps
108.95 Mbit/s
With this patch:
12434.48 tps
145.89 Mbit/s
For TCP_RR, there are 16.6% improvement, TCP_STREAM 33.9%.
Cc: Willem de Bruijn <willemb@google.com>
Cc: Cong Wang <redacted>
Cc: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Tonghao Zhang <redacted>
---
net/core/dev.c | 3 ++-
net/sched/act_api.c | 3 ---
2 files changed, 2 insertions(+), 4 deletions(-)
On Thu, Oct 28, 2021 at 10:28 PM Daniel Borkmann [off-list ref] wrote:
On 10/28/21 3:56 PM, xiangxia.m.yue@gmail.com wrote:
quoted
From: Tonghao Zhang <redacted>
We look up and then check tc_skip_classify flag in net
sched layer, even though skb don't want to be classified.
That case may consume a lot of cpu cycles.
Install the rules as below:
$ for id in $(seq 1 100); do
$ tc filter add ... egress prio $id ... action mirred egress redirect dev ifb0
$ done
Do you actually have such a case in practice or is this just hypothetical?
Hi Daniel, I did some research about this for k8s in production. There
are not so many tc prio(~5 different prio).
butg in this test, I use the 100 prio.
I reviewed the code, for the tx path, I think we check the
tc_skip_classify too later. In the rx path, we check it
in __netif_receive_skb_core.
Asking as this feels rather broken to begin with.
quoted
netperf:
$ taskset -c 1 netperf -t TCP_RR -H ip -- -r 32,32
$ taskset -c 1 netperf -t TCP_STREAM -H ip -- -m 32
Without this patch:
10662.33 tps
108.95 Mbit/s
With this patch:
12434.48 tps
145.89 Mbit/s
For TCP_RR, there are 16.6% improvement, TCP_STREAM 33.9%.
Cc: Willem de Bruijn <willemb@google.com>
Cc: Cong Wang <redacted>
Cc: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Tonghao Zhang <redacted>
---
net/core/dev.c | 3 ++-
net/sched/act_api.c | 3 ---
2 files changed, 2 insertions(+), 4 deletions(-)
From: Daniel Borkmann <daniel@iogearbox.net> Date: 2021-10-29 15:35:13
On 10/29/21 2:04 AM, Tonghao Zhang wrote:
On Thu, Oct 28, 2021 at 10:28 PM Daniel Borkmann [off-list ref] wrote:
quoted
On 10/28/21 3:56 PM, xiangxia.m.yue@gmail.com wrote:
quoted
From: Tonghao Zhang <redacted>
We look up and then check tc_skip_classify flag in net
sched layer, even though skb don't want to be classified.
That case may consume a lot of cpu cycles.
Install the rules as below:
$ for id in $(seq 1 100); do
$ tc filter add ... egress prio $id ... action mirred egress redirect dev ifb0
$ done
Do you actually have such a case in practice or is this just hypothetical?
Hi Daniel, I did some research about this for k8s in production. There
are not so many tc prio(~5 different prio).
butg in this test, I use the 100 prio.
I reviewed the code, for the tx path, I think we check the
tc_skip_classify too later. In the rx path, we check it
in __netif_receive_skb_core.
quoted
Asking as this feels rather broken to begin with.
quoted
netperf:
$ taskset -c 1 netperf -t TCP_RR -H ip -- -r 32,32
$ taskset -c 1 netperf -t TCP_STREAM -H ip -- -m 32
Without this patch:
10662.33 tps
108.95 Mbit/s
With this patch:
12434.48 tps
145.89 Mbit/s
For TCP_RR, there are 16.6% improvement, TCP_STREAM 33.9%.
Cc: Willem de Bruijn <willemb@google.com>
Cc: Cong Wang <redacted>
Cc: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Tonghao Zhang <redacted>
---
net/core/dev.c | 3 ++-
net/sched/act_api.c | 3 ---
2 files changed, 2 insertions(+), 4 deletions(-)
I think this might imply a change in behavior which could have the potential
to break setups in the wild.
we may not change this code, i will send v2, if not comment.
Well none of it I'm afraid, the sch_handle_egress() is out for a very long time by
now and your change could have the potential to break setups in the wild.
quoted
quoted
restart_act_graph:
for (i = 0; i < nr_actions; i++) {
const struct tc_action *a = actions[i];