Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp1653815pxp; Thu, 17 Mar 2022 13:42:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzwUImtXTbkjV60Ajmb5322eD2LeuM/0edllHQ0aNUUZo/aFyC/CSQ92Fe4UmtQ2ZSix+1t X-Received: by 2002:a05:6a02:28e:b0:380:3aee:e863 with SMTP id bk14-20020a056a02028e00b003803aeee863mr5220108pgb.556.1647549725993; Thu, 17 Mar 2022 13:42:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647549725; cv=none; d=google.com; s=arc-20160816; b=P/NRHLEVWqq6YlXYlen8lhIPGFefFA3JYm5Kg41OF2lkVk6R6SCukjzZb1wG9R+Edv u76ni5AHnC6hDPqtDJR/ol7/wLCX3h2DvN8ZchtST/T7VI9203e3bBjJVI2cNcNy/3Wn B79eoNbzC5TyhdNdV6H2iFy+cPdJFFaWQ/gyiMrxx0rkPJzF5+kqRmyi+/tOKEinZcbT W8tQ45M82nkeuUCs/4L5bCE2hfdirTlLS0bwFfxw3b+3AbWSt0dq8AkMgmKEWI0MVA7E slyJsPVZogELeg0E5ppvk2ANT01dvbN/16DgyxgWSpy6vlzriwBdFtw38blYvH+hCJXH mi5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=eIlSa6kmb49A6jcxW6cwLD9pgSEo9IJnzEj0YDWlu10=; b=UVoYDDPtszywTGmiGcEC+BPXexyQpOFT16Fba1MgetGMubt9FBV7Pqm67jWdAqjaQR 47lW7L/uD2ldUWawtT+S2oITkMeTC/ErOmNFa98v+vhS00IV497G642qoH3LiT24Dy+e oH0UoK7u113s2NcMPsnLu7PapxwcrCmqKymBfS/1TK2U7WpS2UQwOu/1MlP0MxrhP9zN 1D5U/xMW8npeu6roxBqNMj3CfboGfhj1mBuXsc48qsyuW4DzyZcbAz2tyxQ1ZwdJ4sJu e/Ew8c2xUQpEFmqVqKLM2eIEeCd2TlPfJjDeooj2eEpMN3YZduERpCBNtE8rP7voCqVY GMpw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=b+KhIddF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id l6-20020a170902ec0600b00153b2d16507si105734pld.271.2022.03.17.13.42.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Mar 2022 13:42:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=b+KhIddF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 7A5CC2EBF83; Thu, 17 Mar 2022 13:10:25 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234471AbiCQNYN (ORCPT + 99 others); Thu, 17 Mar 2022 09:24:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43368 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231321AbiCQNYM (ORCPT ); Thu, 17 Mar 2022 09:24:12 -0400 Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C9A6B1D66FF; Thu, 17 Mar 2022 06:22:50 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id 472E358016A; Thu, 17 Mar 2022 09:22:48 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 17 Mar 2022 09:22:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=eIlSa6kmb49A6jcxW 6cwLD9pgSEo9IJnzEj0YDWlu10=; b=b+KhIddF8J0sNT4bfCDjgMmQrtgAWfXGl EAGO/qPzgdZ58oetHJnYWEDtgsC8NYFKFZklKUEGKvmjmroPe4lDzixrk/hjDUuY KeT8U4Ja4eMn8+Y2aNW+Pc14r7W5QCbiGe4vt/pVCU8sPkJrWywfWCf+tseiOHaW dezo3n2Aire65l6nI/mDxZzlJCYUNOA6P4WFWB4ULobbkr7H344QzQ7T0zkzC3xA EHX//ljz+jIiZRqJpgpIjTgMCXwLqTQXC4YVagPPh91vAFwa4TLYRfPSU8lNBa31 zCBrCESN5LsrQfFZKF0h1YEA5k0bitCpb6ISNatHxAvfB3kIRD3Vw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudefgedghedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefkughoucfu tghhihhmmhgvlhcuoehiughoshgthhesihguohhstghhrdhorhhgqeenucggtffrrghtth gvrhhnpedtffekkeefudffveegueejffejhfetgfeuuefgvedtieehudeuueekhfduheel teenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehiug hoshgthhesihguohhstghhrdhorhhg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 17 Mar 2022 09:22:46 -0400 (EDT) Date: Thu, 17 Mar 2022 15:22:42 +0200 From: Ido Schimmel To: Vladimir Oltean Cc: Jianbo Liu , 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 Message-ID: References: <20220224102908.5255-1-jianbol@nvidia.com> <20220224102908.5255-2-jianbol@nvidia.com> <20220315191358.taujzi2kwxlp6iuf@skbuf> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220315191358.taujzi2kwxlp6iuf@skbuf> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 15, 2022 at 09:13:58PM +0200, Vladimir Oltean wrote: > 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 > > Signed-off-by: Roi Dayan > > Reviewed-by: Ido Schimmel > > --- > > 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? Even if tcf_police_act_to_flow_act() handled "reclassify", the configuration would have been rejected later on by the relevant device driver since they all support "drop" for exceed action and nothing else. I don't know why iproute2 defaults to "reclassify", but the configuration in the example does something different in the SW and HW data paths. One ugly suggestion to keep this case working it to have tcf_police_act_to_flow_act() default to "drop" and emit a warning via extack so that user space is at least aware of this misconfiguration. > > > + 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 > >