Netdev List
 help / color / mirror / Atom feed
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
> 

  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