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 09EE541BE4; Mon, 6 Feb 2023 04:31:39 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DFBFF42B8C; Mon, 6 Feb 2023 04:31:38 +0100 (CET) Received: from mail-vk1-f178.google.com (mail-vk1-f178.google.com [209.85.221.178]) by mails.dpdk.org (Postfix) with ESMTP id BFEC3406A2 for ; Mon, 6 Feb 2023 04:31:37 +0100 (CET) Received: by mail-vk1-f178.google.com with SMTP id b81so5499691vkf.1 for ; Sun, 05 Feb 2023 19:31:37 -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=GlGYbjdzeqyMMlfnuuIyhRJI4tqoUhe1XXI/Jp6VtRo=; b=UH7tUPWXGuAAWpYODhEWDfsNLThJ1C2eDMr6D34CB8pIHbCqCGAxNLhv1ywEno/x0z eSht6tJeGun6QGxI3Gu9/BD8C9pJeqK2J9r2Z22r84XKT/cmrl4NC2i0OizXVWnxmTCx TAAzBW4wSy0vAM8dzON6UmaJ00erNyyEmKSVQqis8yu7e+Nc46AN46Q3/cQnzamwkUHi 6k34ffm2yHdLngFEimsJ+jGuQOg/dFCMKkwIIfOeW+eg0WGujglj6u8RePWxTPD1YavI spoDIfd5/02yZJNrS9ZrZzztzCvIIelrvXBgT/UMfMKufiGFChaIw0WE3C461vdvjXdl a9LQ== 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=GlGYbjdzeqyMMlfnuuIyhRJI4tqoUhe1XXI/Jp6VtRo=; b=slTjXIn25N4qcOY4nBYXK5ZCM94E0sRURGBJtoffiymvhgeCWdCYN6StvdQH7cjHuM fsNO7sXasOOr2UziWyHlcLM216Utip7pAbINviJGrHwVs+sUXf37w4CnYgPR7CJaH0e8 O/cm0ZiSxCmAo1Ftv8LBIxD3rSR+I+qmkC5r9kLZpnaCK11gXKSkCRVcDpnX5Eq2ykgo Pf8AL58pTdKJ/y2/u035SIdvK34bzzKWXFjqE8KaPlSqhmo6WAbK1hRemh92BGfk/65/ 5hgGTDHqLjH+N1A9BdA70NK1hFudub5tIfTHu2FBvPM58odi+nJK+RkrHS6DlMe+M6v1 mwWA== X-Gm-Message-State: AO0yUKWO9V4MqK47RgqY8QZkILmLoQoHDu58k3MeI9EM5zeGnFapuz61 qI7JyA3qxoKMwKmDoZy1KwwPqxs/Sok2zt43vKA= X-Google-Smtp-Source: AK7set9y3CtEGNJYTJ9w2+eqSwylJmY/7fkEFhX1Se/fjAi8e6iTldefdkUxo+B9KVlg5gAHbSztQSXyh8YQBSQ6c+E= X-Received: by 2002:a1f:1708:0:b0:3f8:4f8b:e2cf with SMTP id 8-20020a1f1708000000b003f84f8be2cfmr652763vkx.5.1675654297094; Sun, 05 Feb 2023 19:31:37 -0800 (PST) MIME-Version: 1.0 References: <20221222013904.692922-1-rkudurumalla@marvell.com> <20221221190140.399996e0@hermes.local> In-Reply-To: From: Jerin Jacob Date: Mon, 6 Feb 2023 09:01:10 +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, Feb 2, 2023 at 1:01 PM Ori Kam wrote: > > > > > -----Original Message----- > > From: Jerin Jacob > > Sent: Wednesday, 1 February 2023 20:37 > > > > On Wed, Feb 1, 2023 at 11:19 PM Ori Kam wrote: > > > > > > > > > > > > > -----Original Message----- > > > > From: Jerin Jacob > > > > Sent: Friday, 27 January 2023 8:23 > > > > 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) > > > > > > Subject: Re: [PATCH 1/3] lib: dpdk spec to skip red for ingress policer > > > > > > > > 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]; > > > > }; > > > > > > > > > > > Sorry I'm not sure I understand, > > > I know we can have colors in the meter, but this feature is about > > > somehow telling the rxq to skip the red packet and treat it as green right? > > > > Yes. When rte_mtr_meter_policy_params::actions[RTE_COLOR_GREEN] set > > as > > RTE_FLOW_ACTION_TYPE_SKIP_CMAN for the given meter object, > > it is indicating to SKIP the CMAN configuration applied to the rxq on > > the downstream path if meter assigns a GREEN color. > > (RQ section is as usual as existing path, either via ethdev RSS or > > rte_flow RSS action or rte_fow Queue action). > > > > Sorry for all my questions just trying to find the best solution, > Some follow up questions, > 1. except the skip_cman what other actions is going to be in the action list? Queue? Jump? No specific restriction from speciation POV. Queue, Jump, RSS most useful candidates. > 2. why can't we use the meter color as input if the cman should be skipped or not? Because, cman skip is happening in ethdev Rx and in our case meter object action is the one trigger for this. > > Thanks, > Ori > > > > > > > > > > > > > > Best, > > > > > Ori > > > > >