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 375DFA00C2; Wed, 3 Mar 2021 21:35:56 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BA52240692; Wed, 3 Mar 2021 21:35:55 +0100 (CET) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mails.dpdk.org (Postfix) with ESMTP id 4E23540683 for ; Wed, 3 Mar 2021 21:35:53 +0100 (CET) IronPort-SDR: SXlJfmE6dTBpGhsYTGAxd46FhFXPL3k5aU+3t+FLIwWbIWruXKufcCBHyZlTssmiEyFSLA0bYH b/+QNswDetuA== X-IronPort-AV: E=McAfee;i="6000,8403,9912"; a="206968723" X-IronPort-AV: E=Sophos;i="5.81,220,1610438400"; d="scan'208";a="206968723" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2021 12:35:40 -0800 IronPort-SDR: UWH2wcIf3HMb0uhQxKLFgIi8t/LxGITfM8IZQrGv+o6tsKaqXrdKkE2cTnutbm9v4KfhGRVqID j2RR0rIUgxcQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.81,220,1610438400"; d="scan'208";a="399909335" Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by fmsmga008.fm.intel.com with ESMTP; 03 Mar 2021 12:35:40 -0800 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 3 Mar 2021 12:35:40 -0800 Received: from fmsmsx604.amr.corp.intel.com (10.18.126.84) by fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 3 Mar 2021 12:35:39 -0800 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx604.amr.corp.intel.com (10.18.126.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2 via Frontend Transport; Wed, 3 Mar 2021 12:35:39 -0800 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (104.47.46.59) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2106.2; Wed, 3 Mar 2021 12:35:38 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d3z6ZSfmRgz3eXOPOFbhbvKT3O3zMkKhnOy+fotCzUkkykfFc6tG4nK51VRP4HZBUppVAb0rQWusGjHeFIpqmjwF9Epu51FhEagkJTqfyG6R5qBrjx7do7rDCdlwMuOnWP/GxHdWzoMq2TmaIBO1O9NscCQ4MFdAcEu5u3n2d1aP8P+kub+hnjSh0cWNWBRU/ANa1QSLnLvEVlhn0X2XTBmjU6LlLCo1fHh05f8UBCHn02j/2HFchWIifnRoPK1aIJGVmfvdWQbhOepzAOG2ROorlkCQtAS1kqULn1RfTNGEKDmxsnirXf+PT1176aMlrXd6x5aWFXUEDHsmvRgY7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=23ChQvIOdR4tjaXcJ9pzJwL+TpAmFlQ8v8sJUZS13lE=; b=NuAqRYnEKr+jwcPca1PI3ooyeBp4nyQ3o/VuAJn7fS9Hykw3lhWLiLMM+VacD4sjzOA9RMDFi4x4QwE0PhILYpx4QF3L2t3bXP1xFA8Zo1CUwiDrgPwXPp7vTjAnDJXUuyV8naMFe1soeUFLXjpgN2Jj950rqmc+Ge3ezcsHDDEmVPG+UfA8YqLnRBRidckbvrlK5qENLH7X9w4cDt4km6pYdwmgAo2Vd5ADMEw1C99SvYBbIe7dszfJksRmi9wJNT0KcYCkkDKCPzrdQ1Zm0zcFtBGSl1wbuDwIWVydgnD341ZFne2JZazJg/5PWgAWpVvFaNnOfeuVok6t3VW1cw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=23ChQvIOdR4tjaXcJ9pzJwL+TpAmFlQ8v8sJUZS13lE=; b=MmxQzn31KJhMHEzft/CuEBwz13ET+uuZ1FI5LugMeaJ47Rr2EHIsbHsI9Rr8ctll/pL9JxwIgNXj99SCbB3x2jto40FJJZuIxLn5L2C1LDK/I0+WoH4xCbeCx00tuyWaJWmConnUFgkwCMi7M3Zm7h2mSKOFxwuanaJUU7/lGes= Received: from MWHPR11MB2032.namprd11.prod.outlook.com (2603:10b6:300:2b::13) by MWHPR11MB1629.namprd11.prod.outlook.com (2603:10b6:301:d::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.20; Wed, 3 Mar 2021 20:35:26 +0000 Received: from MWHPR11MB2032.namprd11.prod.outlook.com ([fe80::30c2:967:f635:def2]) by MWHPR11MB2032.namprd11.prod.outlook.com ([fe80::30c2:967:f635:def2%5]) with mapi id 15.20.3890.029; Wed, 3 Mar 2021 20:35:25 +0000 From: "Dumitrescu, Cristian" To: Matan Azrad , Li Zhang , Dekel Peled , Ori Kam , Slava Ovsiienko CC: "dev@dpdk.org" , NBU-Contact-Thomas Monjalon , Raslan Darawsheh , "mb@smartsharesystems.com" , "ajit.khaparde@broadcom.com" , "Yigit, Ferruh" , "Singh, Jasvinder" Thread-Topic: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile Thread-Index: AQHXDoa2zb8ApkK+UkWjVZeNoHieI6pvHMqQgAEqKQCAAFbtcIAABpIAgAAQKdCAAEzhAIABsKEA Date: Wed, 3 Mar 2021 20:35:25 +0000 Message-ID: References: <20210125010235.1768333-1-lizh@nvidia.com> <20210301103532.184983-1-lizh@nvidia.com> <20210301103532.184983-2-lizh@nvidia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.5.1.3 dlp-reaction: no-action dlp-product: dlpe-windows authentication-results: nvidia.com; dkim=none (message not signed) header.d=none;nvidia.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [109.78.54.76] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 131bb7c8-8f5c-4775-c6b0-08d8de83e05c x-ms-traffictypediagnostic: MWHPR11MB1629: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: MppZTEWZ+vpzi+iypKFDJuSbry72vnrTKMSdHQm4fiIYitURnLXPxM+pib6ZBKeaofVTZcIg94uhdbaRqdM3T7jEb3uqKxcuRD2MK5Zr0pu3U8uWEGfO+RZ0s0n3GjWSSeR6tdZOBvz2seeHZjY0IiY5jXC9/RNnnnKZVSB+dUz9dUH4y2UoUxj9y9muSRmWWD9k4FvB8L+5uqzCmLrO6e4RyL9qdJtHGH+u+9VderdS/8EIa8a0DB7AiExWhq2o29qV0WMhZbb3eQgT+ypR4smUJZrluRnRwc2ioHqucgryyPitW540tDA368zDCW+lO5fmX1NWv6ElIWqxGyqCfTdgCGL1RpU9uzk1Ujc8UfosyRxMq89cB/qSdwU7UP8L8eF5LHCiP/m9tGBSVeRzpB6I1yxVghyC22PfCjUcdjucMImbcWHfJOK8c+G5qDM4w6Nddz4Vl+4pJthP+BJZ1ZGuZMwoVYmkdmR2nowB6wus4/JWhPZqicgGfG+6WmwZpTmigXRGBfznYjU+kG4P4A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB2032.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(376002)(39860400002)(136003)(346002)(396003)(66556008)(53546011)(66476007)(8936002)(64756008)(66446008)(66946007)(76116006)(8676002)(54906003)(7696005)(6506007)(2906002)(4326008)(5660300002)(86362001)(52536014)(316002)(110136005)(30864003)(26005)(186003)(107886003)(55016002)(9686003)(478600001)(71200400001)(83380400001)(7416002)(33656002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?a49DvodVi4heozPj4rpD+c/lwCX417hTFi0/rM+V74bPM09WlXFXQ3BCFufI?= =?us-ascii?Q?SmtjJGMm8wFF1X4mrDQvVAH04BTX9S71r/6CBfAawOHiQQ8qFjZdtAHz6wCq?= =?us-ascii?Q?KM/ISauZNVxaeTIJVkoRKd457hcrKGApmfVaq3xdPjdiRsilu1VCEmfWpDzZ?= =?us-ascii?Q?svsO33jpGLg0Q1yK2P0SVO1unWzIif4s8T0SUDnFwWBVgJQTuVVRNBmPmq7q?= =?us-ascii?Q?z6wzFZr1nvlvBzkh6z3Q0lYcZsOn9ltGT4a9VMxh9ltNnUxpT01HCnYOSG0A?= =?us-ascii?Q?bLMA3ICI8YHJBhzhhV0clw/qDOdM2sJ+bH76cZ0QIRb8tP9QBetsTzWZPkpS?= =?us-ascii?Q?m37rZdspY5y9CqptCrZJKqguNskmwUtOLBIRsyYAKELGy6HGhLJrgUaOn2KK?= =?us-ascii?Q?rerie5VvaehI4G7P+jRBeRfTje1tgZRk8ryR+1tM4b3pWC0vla6Er2Un+Dg7?= =?us-ascii?Q?gVfbuU2KwzLbncmcEM+82ciDPO7ABaojsft4SrZeBMFZU7sy5RqCfI8YARZA?= =?us-ascii?Q?kj8ibI/oK6szKPsOxm3EHDLc75fGIA/tkJBvWidobOmFnN53G4z1ny5LB5/C?= =?us-ascii?Q?nu/WCDYF6x8U3SZ/XmsJmZexDYZ0JqAXAFIvQCzJ9eRiHeAwXv9ySgjvmmpZ?= =?us-ascii?Q?T2KMTTUQEeEbGhhmSAu8o01541opRWeR9xeE8Lq5jonFvivG3UOV5x+WikSH?= =?us-ascii?Q?vKLhen5ohUf+p76TIjrqUAnNpy0TCazwLj43w24S8fwk2K9orPwYWEoWJLrq?= =?us-ascii?Q?NonbONiR856ax9Iv8dp/zwNdK+oBvBaDZ1ZhOvISjSQaZG2lGeoL5sDH/Bn5?= =?us-ascii?Q?cKJGGsUcpDvLvqFcXvpk6obDz0cAMSagclHHROR0h2m8rzDecAIb7ufga/5n?= =?us-ascii?Q?isIU2CdQUFERar/rWpFLm0SZ5k3yMH98BzpL1BPqINQCtcEUZPsYHf+H9VOr?= =?us-ascii?Q?Sum+r41TXsTD+Q21OecpW5IcsoxvxVNcO+Fxt+Y2kykn+p868cDQI3SSTrie?= =?us-ascii?Q?COgZykoyjvyPHGZ6R8LGboqKR3y035VddQ6sRI8IZG0z6aC5J5cYirUm3RRR?= =?us-ascii?Q?98JRn0hTSXhV7C4XEwo70Am3CCsaoXYBiqVLdloi7odHUOYM2cKAOEMr/Nc1?= =?us-ascii?Q?G2+Q9Pjb9Y40rkAXjNaohW08zW+9L1++sCFuQXkXrOVGKLz4duizIIDtbqSj?= =?us-ascii?Q?sglKGlFvKN5bY6gv0jICp3/4ogWmUhpms+0yVcQY9NenpGYeTwfIQSgHYub2?= =?us-ascii?Q?LBlJxju6ELuuz6YDIVRGC8Uc+jSOMF07+w8d0xMepD6bU2Ilk4h4xTSmSBQr?= =?us-ascii?Q?3Zu4dCabEFOM6tTWZCZV/lGY?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB2032.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 131bb7c8-8f5c-4775-c6b0-08d8de83e05c X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2021 20:35:25.7504 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: BKynviuwyPyXckNoDjiA8Y73cXOCmXjZAagJqeTsb38En+hux6DOhNVB70uFx5xTbybxEn6KT118no17Ym98OIfLWUREU2L7z97ck5u01A8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1629 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile 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" Hi Matan, > -----Original Message----- > From: Matan Azrad > Sent: Tuesday, March 2, 2021 6:10 PM > To: Dumitrescu, Cristian ; Li Zhang > ; Dekel Peled ; Ori Kam > ; Slava Ovsiienko > Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon > ; Raslan Darawsheh ; > mb@smartsharesystems.com; ajit.khaparde@broadcom.com; Yigit, Ferruh > ; Singh, Jasvinder > Subject: RE: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile >=20 > Hi Cristian >=20 > Good discussion, thank you for that! >=20 > From: Dumitrescu, Cristian > > Hi Matan, > > > > > -----Original Message----- > > > From: Matan Azrad > > > Sent: Tuesday, March 2, 2021 12:37 PM > > > To: Dumitrescu, Cristian ; Li Zhang > > > ; Dekel Peled ; Ori Kam > > > ; Slava Ovsiienko > > > Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon > ; > > > Raslan Darawsheh ; mb@smartsharesystems.com; > > > ajit.khaparde@broadcom.com; Yigit, Ferruh ; > > > Singh, Jasvinder > > > Subject: RE: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile > > > > > > HI Cristian > > > > > > From: Dumitrescu, Cristian > > > > Hi Matan, > > > > > > > > > -----Original Message----- > > > > > From: Matan Azrad > > > > > Sent: Tuesday, March 2, 2021 7:02 AM > > > > > To: Dumitrescu, Cristian ; Li Zhan= g > > > > > ; Dekel Peled ; Ori Kam > > > > > ; Slava Ovsiienko > > > > > Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon > > > ; > > > > > Raslan Darawsheh ; > mb@smartsharesystems.com; > > > > > ajit.khaparde@broadcom.com; Yigit, Ferruh > > > > > ; Singh, Jasvinder > > > > > > > > > > Subject: RE: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profil= e > > > > > > > > > > > > > > > > > > > > Hi Cristian > > > > > > > > > > Thank you for review, please see inline. > > > > > > > > > > From: Dumitrescu, Cristian > > > > > > > From: dev On Behalf Of Li Zhang > > > > > > > > > > > We had this same problem earlier for the rte_tm.h API, where > > > > > > people > > > > > asked to > > > > > > add support for WRED and shaper rates specified in packets to > > > > > > the existing > > > > > byte > > > > > > rate support. I am more than happy to support adding the same > > > > > > here, but please let's adopt the same solution here rather than > > > > > > invent a different approach. > > > > > > > > > > > > Please refer to struct rte_tm_wred_params and struct > > > > > rte_tm_shaper_params > > > > > > from rte_tm.h: the packets vs. bytes mode is explicitly > > > > > > specified through > > > > > the use > > > > > > of a flag called packet_mode that is added to the WRED and > > > > > > shaper > > > profile. > > > > > > When packet_mode is 0, the profile rates and bucket sizes are > > > > > > specified in bytes per second and bytes, respectively; when > > > > > > packet_mode is not 0, the profile rates and bucket sizes are > > > > > > specified in packets and packets per > > > > > second, > > > > > > respectively. The same profile parameters are used, no need to > > > > > > invent additional algorithms (such as srTCM - packet mode) or > > > > > > profile data > > > > > structures. > > > > > > Can we do the same here, please? > > > > > > > > > > This flag approach is very intuitive suggestion and it has advant= ages. > > > > > > > > > > The main problem with the flag approach is that it breaks ABI and= API. > > > > > The profile structure size is changed due to a new field - ABI > breakage. > > > > > The user must initialize the flag with zero to get old behavior - > > > > > API > > > breakage. > > > > > > > > > > > > > The rte_mtr API is experimental, all the API functions are correctl= y > > > > marked with __rte_experimental in rte_mtr.h file, so we can safely > > > > change the API > > > and > > > > the ABI breakage is not applicable here. Therefore, this problem > > > > does not > > > exist, > > > > correct? > > > > > > Yes, but still meter is not new API and I know that a lot of user use= s > > > it for a long time. > > > Forcing them to change while we have good solution that don't force > > > it, looks me problematic. > > > > > > > Not really, only 3 drivers are currently implementing this API. >=20 > The user is not the PMD, the PMDs are the providers. > I'm talking about all our customers, all the current DPDK based applicati= ons > like OVS and others (I familiar with at least 4 ConnectX customer applica= tions) > which use the meter API and I'm sure there are more around the world. >=20 > > Even to these drivers, the required changes are none or extremely small= : > as Ajit > > was also noting, as the default value of 0 continues to represent the > existing > > byte mode, all you have to do is make sure the new flag is set to zero = in the > > profile params structure, which is already done implicitly in most plac= es as > this > > structure is initialized to all-zeros. >=20 > Are you sure all the world initialize the struct to 0? and also in this c= ase, > without new compilation, not all the struct will be zeroes(the old size i= s > smaller). >=20 > > A simple search exercise for struct rte_mtr_meter_profile is all that i= s > needed. > > You also agreed the flag approach is very intuitive, hence better and n= icer, > with > > no additional work needed for you, so why not do it? >=20 > Do you understand that any current application that use the meter API mus= t > recompile the code of the application? Part of them also probably need to > set the flag to 0.... > Do you understand also the potential issues for the applications which ar= e > not aware to the change? Debug time, etc.... >=20 > > > > > I don't see issues with Li suggestion, Do you think Li suggestion > > > > > has critical issues? > > > > > > > > It is probably better to keep the rte_mtr and the rte_tm APIs > > > > aligned, it simplifies the code maintenance and improves the user > > > > experience, which always pays off in the long run. Both APIs > > > > configure token buckets in either packet mode or byte mode, and it > > > > is desirable to have them work in the > > > same > > > > way. Also, I think we should avoid duplicating configuration data > > > > structures > > > for > > > > to support essentially the same algorithms (such as srTCM or trTCM) > > > > if we > > > can. > > > > > > > > > > Yes, but I don't think this motivation is critical. > > > > I really disagree. As API maintainer, making every effort to keep the A= PIs > clear > > and consistent is a critical task for me. >=20 > New pps profile is also clear and simple. >=20 > > We don't want to proliferate the API > > data structures and parameters if there is a good way to avoid it. Espe= cially > in > > cases like this, when the drivers are just beginning to pick up this (s= till > > experimental) API, we have the rare chance to make things right and > therefore > > we should do it. Please also keep in mind that, as more feature are add= ed > to > > the API, small corner cuts like this one that might not look like a big= deal > now, > > eventually come back as unnecessary complexity in the drivers themselve= s. >=20 > I don't see a complexity in the current suggestion. >=20 > > So, please, let's try to keep the quality of the APIs high. >=20 > Also by this way is high. >=20 >=20 > Look, the flag approach is also good and makes the job. > The two approaches are clear, simple and in high quality. > I don't care which one from the 2 to take but I want to be sure we are al= l > understand the pros and cons. >=20 > If you understand my concern on flag approach and still insist to take th= e flag > approach we will align. Yes, thanks for summarizing the pros and cons, I confirm that I do understa= nd your concerns. Yes, sorry to disappoint you, I still think the packet_mode based approach = is better for the long run, as it keeps the APIs clean and consistent. We a= re not adding new algorithms here, we're just adding a new mode to an exist= ing algorithm, so IMO we should not duplicate configuration data structures= and proliferate the number of algorithms artificially. Yes, I do realize that in some limited cases the users will have to explici= tly set the new packet_mode flag to zero or one, in case they need to enabl= e the packet mode, but I think this is an acceptable cost because: (A) This= API is clearly marked as experimental; (B) It is better to take a small in= cremental hit now to keep the APIs in good order rather than taking a bit h= it in a few years as more features are added in the wrong way and the APIs = become unmanageable. >=20 > And if we so, and we are going to break the API\ABI, we are going to > introduce new meter policy API soon and there, breaking API can help, let= s > see in other discussion later. >=20 Yes, as you point out API changes are unavoidable as new features are added= , we have to manage the API evolution correctly. > One more point: > Currently, the meter_id is managed by the user, I think it is better to l= et the > PMDs to manage the meter_id. >=20 > Searching the PMD meter handler inside the PMD is very expensive for the > API call rate when the meter_id is managed by the user. >=20 > Same for profile_id. >=20 > Also all the rte_flow API including the shared action API taking the PMD > management approach. >=20 > What do you think? >=20 Yes, we have carefully considered and discussed both approaches a few years= back when the API was introduced, this is not done by accident :), there a= re pros and cons for each of them. If the object IDs are generated by the driver (outputs of the API), then it= is the user application that needs to keep track of them, which can be ver= y painful. Basically, for each API object the user application needs to cre= ate its own wrapper to store this ID. We basically transfer this problem to= the user app. If the object IDs are generated by the user application (inputs into the AP= I), then we simplify the application by removing and indirection layer. Yes= , it is true that this indirection layer now moves into the driver, but we = should try to make the life easier for the appl developers as opposed to us= , the driver developers. This indirection layer in the driver can be made a= bit smarter than just a slow "for" loop; the search operation can be made = faster with a small bit of effort, such as keeping this list sorted based o= n the object ID, splitting this list into buckets (similar to a hash table)= , etc, right? Having the user app provide the object ID is especially important in the ca= se of rte_tm API, where we have to deal with a tree of nodes, with thousand= s of nodes for each level. Having the app to store and manages this tree of= IDs is a really bad idea, as the user app needs to mirror the tree of node= s on its side for no real benefit. As an added benefit, the user can genera= te these IDs using a rule, such as: given the specific path through the tre= e, the value of the ID can be computed. But again, as you also mention above, there is a list of pros and cons for = every approach, no approach is perfect. We took this approach for the good = reasons listed above. > > > > The flag proposal is actually reducing the amount of work that you > > > > guys > > > need to > > > > do to implement your proposal. There is no negative impact to your > > > proposal > > > > and no big change, right? > > > > > > Yes you right, but the implementation effect is not our concern. > > > > > > > > > > > > This is a quick summary of the required API changes to add > > > > > > support for the packet mode, they are minimal: > > > > > > a) Introduce the packet_mode flag in the profile parameters dat= a > > > > > structure. > > > > > > b) Change the description (comment) of the rate and bucket size > > > > > parameters in > > > > > > the meter profile parameters data structures to reflect that > > > > > > their values represents either bytes or packets, depending on > > > > > > the value of the new flag packet_mode from the same structure. > > > > > > c) Add the relevant capabilities: just search for "packet" in > > > > > > the rte_tm.h capabilities data structures and apply the same to > > > > > > the rte_mtr.h > > > > > capabilities, > > > > > > when applicable. > > > > > > > > > > > Regards, > > > > > > Cristian > > > > > > > > Regards, > > > > Cristian > > > > Regards, > > Cristian Regards, Cristian