From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id C15D4A04FD; Fri, 8 Apr 2022 10:21:41 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B31724069F; Fri, 8 Apr 2022 10:21:41 +0200 (CEST) Received: from mail-io1-f48.google.com (mail-io1-f48.google.com [209.85.166.48]) by mails.dpdk.org (Postfix) with ESMTP id F400D4003F for ; Fri, 8 Apr 2022 10:21:40 +0200 (CEST) Received: by mail-io1-f48.google.com with SMTP id e22so9735336ioe.11 for ; Fri, 08 Apr 2022 01:21:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bo8UF+J11bSEZhQIGS6ANMFx/RnaxjBja2Jm3q85Vc4=; b=o2PTqifS8VqfWLN1ujy+LCQzLxwODpWtDdCTAaNl+1qW0izhxpCN31eiRQ8+mbLvf+ AhpmHi01lDBnkGm6+6dmVURTv7Vghh/C86KChY0gTEO4eE5d5yPCDvR/CSfXqAmcSYQy DIZUrjUHaJZnvkw0k4C0AwAHbtFZ9kw09Aih1Ta9HWJz/tbomio5kkaTCrH7F1tRC8ot V+JBACYK8/hYTtMa1N8d0icnLnEWUHTzRbYsMwmt2kjSqkGK537E8GCtwg73KaouNprN O+i1ofqWeRfIm4VdMeuokZ/KHGdLpIx+5OjHawFtdWl+9wsG+kJKHnKbwUFadtPBhR2g +I3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bo8UF+J11bSEZhQIGS6ANMFx/RnaxjBja2Jm3q85Vc4=; b=7doHM7kswhYI1oIk1UNdZJblGM1BaeSai1TiwQV4GNjsQ2K6Nn+eJ+RqnbR4bTE5u5 YFRPMEPfEuTC5vQWwIWdggcNg4t34DYc4ehjJjWivSslV09c4uGIyBfCKFbagR8ukIFC maDowzfhbvUOHDGQNP8aBKMSaVfDFmBiLGWvKR+gJFiPAVJR8MIktKr/B0ZQe6HUBrCY n+VSkm/IXUGudbihNcbpKCOGPVYEKCpx20t73UGsDpcDzLhV0DxdkAgk0RTBS0Vg7lpx ruIIjyccUYsGO1z3zsxGW9DBNpppM5wkecfVYF2HF/Xg+LzfYHJh7+BpQ+6gWWijwy40 ASmw== X-Gm-Message-State: AOAM531obXlLqbzenZBdcWcS6/o9RUOHMz1Ij+ObuH3umvbSfxqK1icB eTQcilYma9JjVt4sgLoEBnFmoWXf5YWo1n0PcvY= X-Google-Smtp-Source: ABdhPJw6wR9xC/N0tr2/taxEwNs3Bmh3kQYLL1HrWh89pQslR3JD8id/1AW9BGt8/vg+LmICnmgIVwMm6sTMergYLT8= X-Received: by 2002:a05:6602:2cca:b0:646:3d03:a6da with SMTP id j10-20020a0566022cca00b006463d03a6damr7883910iow.121.1649406100215; Fri, 08 Apr 2022 01:21:40 -0700 (PDT) MIME-Version: 1.0 References: <20220408024658.2004918-1-akozyrev@nvidia.com> In-Reply-To: <20220408024658.2004918-1-akozyrev@nvidia.com> From: Jerin Jacob Date: Fri, 8 Apr 2022 13:51:14 +0530 Message-ID: Subject: Re: [RFC] ethdev: datapath-focused meter actions To: Alexander Kozyrev , Cristian Dumitrescu Cc: dpdk-dev , Ori Kam , Thomas Monjalon , Ivan Malov , Andrew Rybchenko , Ferruh Yigit , mohammad.abdul.awal@intel.com, Qi Zhang , Jerin Jacob , Ajit Khaparde , "Richardson, Bruce" Content-Type: text/plain; charset="UTF-8" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org + @Cristian Dumitrescu meter maintainer. On Fri, Apr 8, 2022 at 8:17 AM Alexander Kozyrev wrote: > > The introduction of asynchronous flow rules operations allowed users > to create/destroy flow rules as part of the datapath without blocking > on Flow API and slowing the packet processing down. > > That applies to every possible action that has no preparation steps. > Unfortunately, one notable exception is the meter action. > There is a separate API to prepare a meter profile and a meter policy > before any meter object can be used as a flow rule action. > > The application logic is the following: > 1. rte_mtr_meter_profile_add() is called to create the meter profile > first to define how to classify incoming packets and to assign an > appropriate color to them. > 2. rte_mtr_meter_policy_add() is invoked to define the fate of a packet, > based on its color (practically creating flow rules, matching colors). > 3. rte_mtr_create() is then needed to search (with locks) for previously > created profile and policy in order to create the meter object. > 4. rte_flow_create() is now finally can be used to specify the created > meter as an action. > > This approach doesn't fit into the asynchronous rule creation model > and can be improved with the following proposal: > 1. Creating a policy may be replaced with the creation of a group with > up to 3 different rules for every color using asynchronous Flow API. > That requires the introduction of a new pattern item - meter color. > Then creation a flow rule with the meter means a simple jump to a group: > rte_flow_async_create(group=1, pattern=color, actions=...); > rte_flow_async_create(group=0, pattern=5-tuple, > actions=meter,jump group 1); > This allows to classify packets and act upon their color classifications. > The Meter action assigns a color to a packet and an appropriate action > is selected based on the Meter color in group 1. > > 2. Preparing a meter object should be the part of flow rule creation > and use the same flow queue to benefit from asynchronous operations: > rte_flow_async_create(group=0, pattern=5-tuple, > actions=meter id 1 profile rfc2697, jump group 1); > Creation of the meter object takes time and flow creation must wait > until it is ready before inserting the rule. Using the same queue allows > ensuring that. There is no need to create a meter object outside of the > Flow API, but this approach won't affect the old Meter API in any way. > > 3. Another point of optimization is to prepare all the resources needed > in advance in rte_flow_configure(). All the policy rules can be created > during the initialization stage easily and put into several groups. > These groups can be used by many meter objects by simple jump action to > an appropriate group. Meter objects can be preallocated as well and > configured with required profile parameters later at the flow rule > creation stage. The number of pre-allocated profiles/policies is > specified in the Flow engine resources settings. > > These optimizations alongside already existing pattern/actions templates > can improve the insertion rate significantly and allow meter usage as > part of the datapath. The introduction of the new API is intended to be > used with the asynchronous Flow API. Deprecation of the old Meter API > is not planned at this point. > > Signed-off-by: Alexander Kozyrev > --- > lib/ethdev/rte_flow.h | 71 ++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 70 insertions(+), 1 deletion(-) > > diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h > index d8827dd184..aec36a9f0a 100644 > --- a/lib/ethdev/rte_flow.h > +++ b/lib/ethdev/rte_flow.h > @@ -33,6 +33,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -671,6 +672,13 @@ enum rte_flow_item_type { > * See struct rte_flow_item_gre_opt. > */ > RTE_FLOW_ITEM_TYPE_GRE_OPTION, > + > + /** > + * Matches Meter Color. > + * > + * See struct rte_flow_item_meter_color. > + */ > + RTE_FLOW_ITEM_TYPE_METER_COLOR, > }; > > /** > @@ -1990,6 +1998,26 @@ static const struct rte_flow_item_ppp rte_flow_item_ppp_mask = { > }; > #endif > > +/** > + * @warning > + * @b EXPERIMENTAL: this structure may change without prior notice > + * > + * RTE_FLOW_ITEM_TYPE_METER_COLOR > + * > + * Matches a meter color set in the packet meta-data > + * (i.e. struct rte_mbuf::sched::color). > + */ > +struct rte_flow_item_meter_color { > + enum rte_color color; /**< Packet color. */ > +}; > + > +/** Default mask for RTE_FLOW_ITEM_TYPE_METER_COLOR. */ > +#ifndef __cplusplus > +static const struct rte_flow_item_meter_color rte_flow_item_meter_color_mask = { > + .color = 0x3, > +}; > +#endif > + > /** > * Matching pattern item definition. > * > @@ -2376,6 +2404,14 @@ enum rte_flow_action_type { > */ > RTE_FLOW_ACTION_TYPE_METER, > > + /** > + * Extended Traffic metering and policing (MTR). > + * > + * See struct rte_flow_action_meter_ext. > + * See file rte_mtr.h for MTR object configuration. > + */ > + RTE_FLOW_ACTION_TYPE_METER_EXT, > + > /** > * Redirects packets to security engine of current device for security > * processing as specified by security session. > @@ -3128,6 +3164,19 @@ struct rte_flow_action_meter { > uint32_t mtr_id; /**< MTR object ID created with rte_mtr_create(). */ > }; > > +/** > + * RTE_FLOW_ACTION_TYPE_METER_EXT > + * > + * Extended Traffic metering and policing (MTR). > + * > + * Packets matched by items of this type can be either dropped or passed to the > + * next item with their color set by the MTR object. > + */ > +struct rte_flow_action_meter_ext { > + uint32_t mtr_id; /**< MTR object ID. */ > + struct rte_meter_profile *profile; /**< MTR profile. */ > +}; > + > /** > * RTE_FLOW_ACTION_TYPE_SECURITY > * > @@ -4899,10 +4948,20 @@ struct rte_flow_port_info { > */ > uint32_t max_nb_aging_objects; > /** > - * Maximum number traffic meters. > + * Maximum number of traffic meters. > * @see RTE_FLOW_ACTION_TYPE_METER > */ > uint32_t max_nb_meters; > + /** > + * Maximum number of traffic meter profiles. > + * @see RTE_FLOW_ACTION_TYPE_METER > + */ > + uint32_t max_nb_meter_profiles; > + /** > + * Maximum number of traffic meters policices. > + * @see RTE_FLOW_ACTION_TYPE_METER > + */ > + uint32_t max_nb_meter_policies; > }; > > /** > @@ -4972,6 +5031,16 @@ struct rte_flow_port_attr { > * @see RTE_FLOW_ACTION_TYPE_METER > */ > uint32_t nb_meters; > + /** > + * Number of meter profiles to configure. > + * @see RTE_FLOW_ACTION_TYPE_METER > + */ > + uint32_t nb_meter_profiles; > + /** > + * Number of meter policies to configure. > + * @see RTE_FLOW_ACTION_TYPE_METER > + */ > + uint32_t nb_meter_policies; > }; > > /** > -- > 2.18.2 >