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 29BE1A034F; Mon, 29 Mar 2021 12:38:56 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9158840151; Mon, 29 Mar 2021 12:38:55 +0200 (CEST) Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) by mails.dpdk.org (Postfix) with ESMTP id B599D40042 for ; Mon, 29 Mar 2021 12:38:54 +0200 (CEST) Received: by mail-io1-f47.google.com with SMTP id z136so12197437iof.10 for ; Mon, 29 Mar 2021 03:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NdIe0W2T7EtPvI22GH9A6PS2veDdxVjRvdyhCakrX9o=; b=keKoNTNJVjszvAaCs61PlHqL2FNPvoyi4J/LPcfv1g6DPDhYGAB6T/HSsAHxdIMEqE NZb3PaClpumsq5cpWJwEIN18x53mpHsLxCQd6l3ec0X0q9NWuaUbdh8BVVPGF+BeywvN 4Mic0FpXtC69Rji8GDSfkcIMfzWgJxzPNeAgQU7pvSCdYQ7LMepKC9IDB+eAu4h6Z7Ba sA5zWEIiycElDn30Ic4LEUkb3nNLdmg3HzVkSg11wVCVTE1woran+vsAC0zYhO96upsH /SvXAKjDW3zVsFundMY8vkYepjt/Agz2H9CpJPLS6qwqrmqYYJkGIa3VEM4p6wEaxpwK z6hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NdIe0W2T7EtPvI22GH9A6PS2veDdxVjRvdyhCakrX9o=; b=F6vX0aUv87fBpJmcc3GsBxIWX9H5dmg3wJMdK0/8y6LuggzFlcqppdXKEckU0YX7h+ o8twOoEDOMmhA8hwcO20tyJxkTWy11cM/lvZlHcsFb6eZ15S3HaOtv8s7LGKEp5snHlO NeSyCCaE3Ix5udXVnCbDDsULzwShW1q2OvY8TVvXnidh+M3aC7xJpcOrHXkZOzzFcVqr nHHm31vRnmNAGxyvIJ+mgiYfgArsMZUp+0nPiGFiSTcFduBIQqhoUP/ttfxug/cpWs/B X7VUBuEC4o/M3qt5NeeQFqIpls/VyXjNfa9GQoO54Ql3fDv5Xfv//AcDbjloJfbRwS0w VmVw== X-Gm-Message-State: AOAM5312hCarWwWUC2D/gYhSzLildQU/zJjyzFQuXEcfItAuqWR5GQqy HdxQ2ZgoxbfOAO7O/aPrvTL+8qLZ2szMa4uE7o4= X-Google-Smtp-Source: ABdhPJwJR20YKt+5hsqq7Z4SEl3ZxEzpWsQ+/HIUm+hmNFgD6sSk7TNdeLNJh+RWZPczKpo7H9GmkSm9r/oMnVnGOXo= X-Received: by 2002:a6b:b7cd:: with SMTP id h196mr18999921iof.59.1617014334042; Mon, 29 Mar 2021 03:38:54 -0700 (PDT) MIME-Version: 1.0 References: <20210318085815.804896-1-lizh@nvidia.com> In-Reply-To: <20210318085815.804896-1-lizh@nvidia.com> From: Jerin Jacob Date: Mon, 29 Mar 2021 16:08:38 +0530 Message-ID: To: Li Zhang Cc: Dekel Peled , Ori Kam , Viacheslav Ovsiienko , Matan Azrad , Shahaf Shuler , Liron Himi , Jasvinder Singh , Thomas Monjalon , Ferruh Yigit , Andrew Rybchenko , Cristian Dumitrescu , dpdk-dev , Raslan Darawsheh , Roni Bar Yanai Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH 1/2] [RFC]: ethdev: add pre-defined meter policy API 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 Sender: "dev" On Thu, Mar 18, 2021 at 2:28 PM Li Zhang wrote: > > Currently, the flow meter policy does not support multiple actions > per color; also the allowed action types per color are very limited. > In addition, the policy cannot be pre-defined. > > Due to the growing in flow actions offload abilities there is a potential > for the user to use variety of actions per color differently. > This new meter policy API comes to allow this potential in the most ethdev > common way using rte_flow action definition. > A list of rte_flow actions will be provided by the user per color > in order to create a meter policy. > In addition, the API forces to pre-define the policy before > the meters creation in order to allow sharing of single policy > with multiple meters efficiently. > > meter_policy_id is added into struct rte_mtr_params. > So that it can get the policy during the meters creation. > > Policy id 0 is default policy. Action per color as below: > green - no action, yellow - no action, red - drop > > Allow coloring the packet using a new rte_flow_action_color > as could be done by the old policy API, > > The next API function were added: > - rte_mtr_meter_policy_add > - rte_mtr_meter_policy_delete > - rte_mtr_meter_policy_update > - rte_mtr_meter_policy_validate > The next struct was changed: > - rte_mtr_params > - rte_mtr_capabilities > The next API was deleted: > - rte_mtr_policer_actions_update > > Signed-off-by: Li Zhang > --- > lib/librte_ethdev/rte_flow.h | 18 ++++ > lib/librte_ethdev/rte_mtr.c | 55 ++++++++-- > lib/librte_ethdev/rte_mtr.h | 166 ++++++++++++++++++++--------- > lib/librte_ethdev/rte_mtr_driver.h | 45 ++++++-- > 4 files changed, 210 insertions(+), 74 deletions(-) > > diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h > index 669e677e91..5f38aa7fa4 100644 > --- a/lib/librte_ethdev/rte_flow.h > +++ b/lib/librte_ethdev/rte_flow.h > @@ -31,6 +31,7 @@ > #include > #include > #include > +#include > > #ifdef __cplusplus > extern "C" { > @@ -2236,6 +2237,13 @@ enum rte_flow_action_type { > * See struct rte_flow_action_modify_field. > */ > RTE_FLOW_ACTION_TYPE_MODIFY_FIELD, > + > + /** > + * Color the packet to reflect the meter color result. > + * > + * See struct rte_flow_action_color. > + */ > + RTE_FLOW_ACTION_TYPE_COlOR, Based on my understanding of this API, 1) Application creates the policy 2) Attachs the policy ID to meter object in params If so, Why we need this new action? > }; > > /** > @@ -2828,6 +2836,16 @@ struct rte_flow_action_set_dscp { > */ > struct rte_flow_shared_action; > > +/** > + * Meter policy add > + * > + * Create a new meter policy. The new policy > + * is used to create single or multiple MTR objects. > + * > + * @param[in] port_id > + * The port identifier of the Ethernet device. > + * @param[in] policy_id > + * Policy identifier for the new meter policy. > + * @param[in] actions > + * Associated actions per color. > + * list NULL is legal and means no special action. > + * (list terminated by the END action). > + * @param[out] error > + * Error details. Filled in only on error, when not NULL. > + * @return > + * 0 on success, non-zero error code otherwise. > + */ > +__rte_experimental > +int > +rte_mtr_meter_policy_add(uint16_t port_id, _create() may be better here instead of _add() as you have used _delete() > + uint32_t policy_id, > + const struct rte_flow_action *actions[RTE_COLORS], 1) Does this mean that MLX HW can support any rte_flow actions like, if packet color is green do RTE_FLOW_ACTION_TYPE_SECURITY etc. 2) Is there any real-world use case other than using normal action like pass or drop as it is used in conjunction with meter object? 3) Marvell HW has the following policy actions a) PASS b) DROP c) RED (Random early discard) Both (a) and (c) are not in enumated as rte_flow_actions. Should we take rte_flow_action or create meter-specific policy actions?