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 C1B024249A; Fri, 27 Jan 2023 07:23:46 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6DEF140150; Fri, 27 Jan 2023 07:23:46 +0100 (CET) Received: from mail-vs1-f53.google.com (mail-vs1-f53.google.com [209.85.217.53]) by mails.dpdk.org (Postfix) with ESMTP id CD49D40146 for ; Fri, 27 Jan 2023 07:23:45 +0100 (CET) Received: by mail-vs1-f53.google.com with SMTP id d66so4300124vsd.9 for ; Thu, 26 Jan 2023 22:23:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/B5bd6YrVhkkAhlZtP2Jk69Ndb5U9OJIKnyl4/9JgTM=; b=WgcvZHFEw+KuR2o5Ewt/d7zoXNk1MA6hzElldYNzcDmrvS8LakN+ykLJYy25dlZliM Enid/S8pIghRxARbn0HRk3p04i+LqpxYB80amavDGoXKmPA1RAPivUzSgWnR9T7Yk1Bt N+9pZRhTchukWhuP++xOw6rUlEJ16fAwXp+j1wuusVpnJZXU7RSIvqE0eGtXGXLDDqUx QEG8E7igUgiJHJzTzv6ZMC/C7PP4FoczlRKzu7cQpOMYzA/j9LWJjCw2jOdz+APhAEY0 x/1OF7c4VsceyZIPDlEHxLk3Sbsg2DX503ncLWHeMUfkEAj6oPpj6RXPzewT5BdQOMXC bFjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/B5bd6YrVhkkAhlZtP2Jk69Ndb5U9OJIKnyl4/9JgTM=; b=oqMaElSGmnjXXTPkfapH4n2bPezywVKnTRz5eguvMKf/wjrFUhkud8sWLKqehGinQ4 ZVGulRLMKegkTRmBp4XjjMRpGNJ4NEjMLi9wTTHRLAQXdmulRk15hWLwPRWP9UmwZXjK q6lwDkTe0ZNGRWglxx9UzcU2LkoDq3zw5fEM38lQLHC2p07jPB/K+rT+TWIQU6hCNevL O0D5TESPH6EsBLrzCV/5QjqBgIQ3sKifeSqVjjjvi5kpZeAdqOm+PsBCS8VV4QwQUkOr 11MOKLLB03fXGcX1GothAaimeygeSt5YPqI4zZ9ulOmfsnpd9KWHWfq/eBNwkYAHRujE O+Qw== X-Gm-Message-State: AFqh2kpJcj465CiEp0kTvQvbCm1zETPJAKDnVBpf+zc5ka8jSxBu1+M0 4lcvoks33NzXvuIYl7NNNC4iKN9jDc9efZooiMU= X-Google-Smtp-Source: AMrXdXuziFYuv+v5mbHL3rITf5uJkGCuYKNFdN8EDSC7jGtMxYil0qrC5g1ca5A0Uq6ZnDwcCHM6ojDGqSi3KLHO5Pg= X-Received: by 2002:a67:b64b:0:b0:3d0:c96e:25ac with SMTP id e11-20020a67b64b000000b003d0c96e25acmr4991723vsm.73.1674800625076; Thu, 26 Jan 2023 22:23:45 -0800 (PST) MIME-Version: 1.0 References: <20221222013904.692922-1-rkudurumalla@marvell.com> <20221221190140.399996e0@hermes.local> In-Reply-To: From: Jerin Jacob Date: Fri, 27 Jan 2023 11:53:18 +0530 Message-ID: Subject: Re: [PATCH 1/3] lib: dpdk spec to skip red for ingress policer To: Ori Kam Cc: Rakesh Kudurumalla , Stephen Hemminger , "NBU-Contact-Thomas Monjalon (EXTERNAL)" , Ferruh Yigit , Andrew Rybchenko , "dev@dpdk.org" , "NBU-Contact-Adrien Mazarguil (EXTERNAL)" 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 On Thu, Jan 26, 2023 at 8:43 PM Ori Kam wrote: > > > > > -----Original Message----- > > From: Rakesh Kudurumalla > > Sent: Wednesday, 18 January 2023 10:10 > > > > > > > -----Original Message----- > > > From: Rakesh Kudurumalla > > > Sent: Tuesday, January 10, 2023 12:12 PM > > > To: Ori Kam ; Jerin Jacob ; > > > Stephen Hemminger > > > Cc: NBU-Contact-Thomas Monjalon (EXTERNAL) ; > > > Ferruh Yigit ; Andrew Rybchenko > > > ; dev@dpdk.org; NBU-Contact-Adrien > > > Mazarguil (EXTERNAL) > > > Subject: RE: [PATCH 1/3] lib: dpdk spec to skip red for ingress policer > > > > > > > > > > > > > -----Original Message----- > > > > From: Ori Kam > > > > Sent: Monday, December 26, 2022 10:30 PM > > > > To: Jerin Jacob ; Stephen Hemminger > > > > > > > > Cc: Rakesh Kudurumalla ; NBU-Contact- > > > Thomas > > > > Monjalon (EXTERNAL) ; Ferruh Yigit > > > > ; Andrew Rybchenko > > > > ; dev@dpdk.org; NBU-Contact- > > Adrien > > > > Mazarguil (EXTERNAL) > > > > Subject: [EXT] RE: [PATCH 1/3] lib: dpdk spec to skip red for ingress > > > > policer > > > > > > > > External Email > > > > > > > > ---------------------------------------------------------------------- > > > > Hi All, > > > > > > > > > -----Original Message----- > > > > > From: Jerin Jacob > > > > > Sent: Thursday, 22 December 2022 7:27 > > > > > > > > > > On Thu, Dec 22, 2022 at 8:32 AM Stephen Hemminger > > > > > wrote: > > > > > > > > > > > > On Thu, 22 Dec 2022 07:09:02 +0530 Rakesh Kudurumalla > > > > > > wrote: > > > > > > > > > > > > > Dropping of packets based on RED can be skipped with meter > > > > > > > action, when RED is configured using > > > > > > > rte_eth_cman_config_set() > > > > > > > > > > > > > > Signed-off-by: Rakesh Kudurumalla > > > > > > > > > > > > Should this be more general and apply to all congestion management > > > > > > options. Assuming the hardware can do something better than RED. > > > > > > > > > > Yes. We can use "enum rte_cman_mode mode" in the descriptor to > > > > > future- proof. > > > > > > > > I'm missing the idea of this new action, I understand that is related > > > > to Jerin congestion patches. > > > > But I fail to see why we need it? Is it to mark some metadata that > > > > will have some effect on the congestion result? (I assume the system > > > > is implemented in the HW) > > > > > > Yes. It is implemented in HW. Congestion management is applied on > > ethdev > > > Rx queue using rte_eth_cman_config() API. Once it is configured, it applies > > to > > > all the packets that steer towards that particular ethdev Rx queue. This > > > feature help to skip the congestion management processing based on the > > > packet color identified by the rte_flow meter object. For example, If one > > Rx > > > queue configured as RED congestion and application wants to bypass the > > > RED congestion processing for all GREEN color packet can be expressed > > > though this API proposal. > > > > Hi Ori Kam, > > > > Let me know if above information would give clear idea on skip RED action > > I think so, to put it in my own words, when setting this the selected packet is treated as > green packet? > > If so, can we use the meter_color field? If you want the packet to be green just set the > field to green? It is already there in one form. See following in existing header file. /** * Meter policy */ struct rte_mtr_meter_policy_params { /** * Policy action list per color. * actions[i] potentially represents a chain of rte_flow actions * terminated by the END action, exactly as specified by the rte_flow * API for the flow definition, and not just a single action. */ const struct rte_flow_action *actions[RTE_COLORS]; }; > > Best, > Ori >