From: Vladimir Oltean <olteanv@gmail.com>
To: Jianbo Liu <jianbol@nvidia.com>
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, andrew@lunn.ch,
vivien.didelot@gmail.com, f.fainelli@gmail.com,
davem@davemloft.net, kuba@kernel.org, rajur@chelsio.com,
claudiu.manoil@nxp.com, sgoutham@marvell.com, gakula@marvell.com,
sbhatta@marvell.com, hkelam@marvell.com, saeedm@nvidia.com,
leon@kernel.org, idosch@nvidia.com, petrm@nvidia.com,
alexandre.belloni@bootlin.com, UNGLinuxDriver@microchip.com,
simon.horman@corigine.com, jhs@mojatatu.com,
xiyou.wangcong@gmail.com, jiri@resnulli.us,
baowen.zheng@corigine.com, louis.peens@netronome.com,
peng.zhang@corigine.com, oss-drivers@corigine.com,
roid@nvidia.com
Subject: Re: [PATCH net-next v3 1/2] net: flow_offload: add tc police action parameters
Date: Tue, 15 Mar 2022 21:13:58 +0200 [thread overview]
Message-ID: <20220315191358.taujzi2kwxlp6iuf@skbuf> (raw)
In-Reply-To: <20220224102908.5255-2-jianbol@nvidia.com>
Hello Jianbo,
On Thu, Feb 24, 2022 at 10:29:07AM +0000, Jianbo Liu wrote:
> The current police offload action entry is missing exceed/notexceed
> actions and parameters that can be configured by tc police action.
> Add the missing parameters as a pre-step for offloading police actions
> to hardware.
>
> Signed-off-by: Jianbo Liu <jianbol@nvidia.com>
> Signed-off-by: Roi Dayan <roid@nvidia.com>
> Reviewed-by: Ido Schimmel <idosch@nvidia.com>
> ---
> include/net/flow_offload.h | 9 +++++++
> include/net/tc_act/tc_police.h | 30 ++++++++++++++++++++++
> net/sched/act_police.c | 46 ++++++++++++++++++++++++++++++++++
> 3 files changed, 85 insertions(+)
>
> diff --git a/include/net/flow_offload.h b/include/net/flow_offload.h
> index 5b8c54eb7a6b..74f44d44abe3 100644
> --- a/include/net/flow_offload.h
> +++ b/include/net/flow_offload.h
> @@ -148,6 +148,8 @@ enum flow_action_id {
> FLOW_ACTION_MPLS_MANGLE,
> FLOW_ACTION_GATE,
> FLOW_ACTION_PPPOE_PUSH,
> + FLOW_ACTION_JUMP,
> + FLOW_ACTION_PIPE,
> NUM_FLOW_ACTIONS,
> };
>
> @@ -235,9 +237,16 @@ struct flow_action_entry {
> struct { /* FLOW_ACTION_POLICE */
> u32 burst;
> u64 rate_bytes_ps;
> + u64 peakrate_bytes_ps;
> + u32 avrate;
> + u16 overhead;
> u64 burst_pkt;
> u64 rate_pkt_ps;
> u32 mtu;
> + struct {
> + enum flow_action_id act_id;
> + u32 extval;
> + } exceed, notexceed;
> } police;
> struct { /* FLOW_ACTION_CT */
> int action;
> diff --git a/include/net/tc_act/tc_police.h b/include/net/tc_act/tc_police.h
> index 72649512dcdd..283bde711a42 100644
> --- a/include/net/tc_act/tc_police.h
> +++ b/include/net/tc_act/tc_police.h
> @@ -159,4 +159,34 @@ static inline u32 tcf_police_tcfp_mtu(const struct tc_action *act)
> return params->tcfp_mtu;
> }
>
> +static inline u64 tcf_police_peakrate_bytes_ps(const struct tc_action *act)
> +{
> + struct tcf_police *police = to_police(act);
> + struct tcf_police_params *params;
> +
> + params = rcu_dereference_protected(police->params,
> + lockdep_is_held(&police->tcf_lock));
> + return params->peak.rate_bytes_ps;
> +}
> +
> +static inline u32 tcf_police_tcfp_ewma_rate(const struct tc_action *act)
> +{
> + struct tcf_police *police = to_police(act);
> + struct tcf_police_params *params;
> +
> + params = rcu_dereference_protected(police->params,
> + lockdep_is_held(&police->tcf_lock));
> + return params->tcfp_ewma_rate;
> +}
> +
> +static inline u16 tcf_police_rate_overhead(const struct tc_action *act)
> +{
> + struct tcf_police *police = to_police(act);
> + struct tcf_police_params *params;
> +
> + params = rcu_dereference_protected(police->params,
> + lockdep_is_held(&police->tcf_lock));
> + return params->rate.overhead;
> +}
> +
> #endif /* __NET_TC_POLICE_H */
> diff --git a/net/sched/act_police.c b/net/sched/act_police.c
> index 0923aa2b8f8a..a2275eef6877 100644
> --- a/net/sched/act_police.c
> +++ b/net/sched/act_police.c
> @@ -405,20 +405,66 @@ static int tcf_police_search(struct net *net, struct tc_action **a, u32 index)
> return tcf_idr_search(tn, a, index);
> }
>
> +static int tcf_police_act_to_flow_act(int tc_act, u32 *extval)
> +{
> + int act_id = -EOPNOTSUPP;
> +
> + if (!TC_ACT_EXT_OPCODE(tc_act)) {
> + if (tc_act == TC_ACT_OK)
> + act_id = FLOW_ACTION_ACCEPT;
> + else if (tc_act == TC_ACT_SHOT)
> + act_id = FLOW_ACTION_DROP;
> + else if (tc_act == TC_ACT_PIPE)
> + act_id = FLOW_ACTION_PIPE;
> + } else if (TC_ACT_EXT_CMP(tc_act, TC_ACT_GOTO_CHAIN)) {
> + act_id = FLOW_ACTION_GOTO;
> + *extval = tc_act & TC_ACT_EXT_VAL_MASK;
> + } else if (TC_ACT_EXT_CMP(tc_act, TC_ACT_JUMP)) {
> + act_id = FLOW_ACTION_JUMP;
> + *extval = tc_act & TC_ACT_EXT_VAL_MASK;
> + }
> +
> + return act_id;
> +}
> +
> static int tcf_police_offload_act_setup(struct tc_action *act, void *entry_data,
> u32 *index_inc, bool bind)
> {
> if (bind) {
> struct flow_action_entry *entry = entry_data;
> + struct tcf_police *police = to_police(act);
> + struct tcf_police_params *p;
> + int act_id;
> +
> + p = rcu_dereference_protected(police->params,
> + lockdep_is_held(&police->tcf_lock));
>
> entry->id = FLOW_ACTION_POLICE;
> entry->police.burst = tcf_police_burst(act);
> entry->police.rate_bytes_ps =
> tcf_police_rate_bytes_ps(act);
> + entry->police.peakrate_bytes_ps = tcf_police_peakrate_bytes_ps(act);
> + entry->police.avrate = tcf_police_tcfp_ewma_rate(act);
> + entry->police.overhead = tcf_police_rate_overhead(act);
> entry->police.burst_pkt = tcf_police_burst_pkt(act);
> entry->police.rate_pkt_ps =
> tcf_police_rate_pkt_ps(act);
> entry->police.mtu = tcf_police_tcfp_mtu(act);
> +
> + act_id = tcf_police_act_to_flow_act(police->tcf_action,
> + &entry->police.exceed.extval);
I don't know why just now, but I observed an apparent regression here
with these commands:
root@debian:~# tc qdisc add dev swp3 clsact
root@debian:~# tc filter add dev swp3 ingress protocol ip flower skip_sw ip_proto icmp action police rate 100Mbit burst 10000
[ 45.767900] tcf_police_act_to_flow_act: 434: tc_act 1
[ 45.773100] tcf_police_offload_act_setup: 475, act_id -95
Error: cls_flower: Failed to setup flow action.
We have an error talking to the kernel, -1
The reason why I'm not sure is because I don't know if this should have
worked as intended or not. I am remarking just now in "man tc-police"
that the default conform-exceed action is "reclassify".
So if I specify "conform-exceed drop", things are as expected, but with
the default (implicitly "conform-exceed reclassify") things fail with
-EOPNOTSUPP because tcf_police_act_to_flow_act() doesn't handle a
police->tcf_action of TC_ACT_RECLASSIFY.
Should it?
> + if (act_id < 0)
> + return act_id;
> +
> + entry->police.exceed.act_id = act_id;
> +
> + act_id = tcf_police_act_to_flow_act(p->tcfp_result,
> + &entry->police.notexceed.extval);
> + if (act_id < 0)
> + return act_id;
> +
> + entry->police.notexceed.act_id = act_id;
> +
> *index_inc = 1;
> } else {
> struct flow_offload_action *fl_action = entry_data;
> --
> 2.26.2
>
next prev parent reply other threads:[~2022-03-15 19:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-24 10:29 [PATCH net-next v3 0/2] flow_offload: add tc police parameters Jianbo Liu
2022-02-24 10:29 ` [PATCH net-next v3 1/2] net: flow_offload: add tc police action parameters Jianbo Liu
2022-03-15 19:13 ` Vladimir Oltean [this message]
2022-03-17 13:22 ` Ido Schimmel
2022-03-17 18:52 ` Vladimir Oltean
2022-03-17 19:37 ` Ido Schimmel
2022-03-22 10:13 ` Ido Schimmel
2022-04-06 14:30 ` Vladimir Oltean
2022-02-24 10:29 ` [PATCH net-next v3 2/2] flow_offload: reject offload for all drivers with invalid police parameters Jianbo Liu
2022-02-28 11:40 ` [PATCH net-next v3 0/2] flow_offload: add tc " patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220315191358.taujzi2kwxlp6iuf@skbuf \
--to=olteanv@gmail.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=alexandre.belloni@bootlin.com \
--cc=andrew@lunn.ch \
--cc=baowen.zheng@corigine.com \
--cc=claudiu.manoil@nxp.com \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=gakula@marvell.com \
--cc=hkelam@marvell.com \
--cc=idosch@nvidia.com \
--cc=jhs@mojatatu.com \
--cc=jianbol@nvidia.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=louis.peens@netronome.com \
--cc=netdev@vger.kernel.org \
--cc=oss-drivers@corigine.com \
--cc=peng.zhang@corigine.com \
--cc=petrm@nvidia.com \
--cc=rajur@chelsio.com \
--cc=roid@nvidia.com \
--cc=saeedm@nvidia.com \
--cc=sbhatta@marvell.com \
--cc=sgoutham@marvell.com \
--cc=simon.horman@corigine.com \
--cc=vivien.didelot@gmail.com \
--cc=xiyou.wangcong@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox