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 6A69EA0A02; Thu, 25 Mar 2021 09:21:39 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EFE224067B; Thu, 25 Mar 2021 09:21:38 +0100 (CET) Received: from NAM04-DM6-obe.outbound.protection.outlook.com (mail-dm6nam08on2072.outbound.protection.outlook.com [40.107.102.72]) by mails.dpdk.org (Postfix) with ESMTP id 8956440147 for ; Thu, 25 Mar 2021 09:21:37 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VQDoFnETl3d3BbM1nTWi+BLDqZDlbZTQ3kzxLdpXdADe9P/TjSmKZHe8zGuVnhVocLnoc5RcLbtiNNiTduwOCaRan2l4vdPk7Ws9HbhKV+QbAcheDCQ+7X5MCvWPIdmR0/utzbCTryAQIsfeuPs3NyE5Yg6SRs8Ozu8IQr9mLlVzRVS9pzHe7id6iKSn0mBuZfEl1BdIXfrDYmA/xVipibnc2PNRpmc3ocOgv16ss+0HCpfSRNd6OTsTdXCwNVWDXVUqCCV++QURehT7O5wBSfElTrw34Ts4+u2Sgf2HhJmqJd/9aFHgr8culy9eYlk6H2+2jE5y8XjS8uDTxjIVLg== 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=yBO5F4AgPJPLPNK7H4fH2SfT8jQvNwPOrVI8zN+F4CM=; b=LSdA/FA0NnwJPfi9dRNQuwOW09pDfseb+g1WpZBd0TP3TI/+n0N8xAo6PEFfV5OwDRD9lDxLz3fj7NbR6KSAAbh1oF00TuFZHnROb71YepbtGhyO6M52XyDmmYPV3YuiQZG0aWORXPSa7aJbVBmsJL/i4fj17ZXjC1irxoO36zsBd3SecIbM73LAXFBz6MPQBDc0zFJV/Z6C52p5Y4V6+xD+zQjg0iVgdHj6cCJBJ/SPSZH03tzXrvtjC2YsRuZI+TmaK1Ypz9e8SO9d8gOg8/HhBN5MNYUThin1cERl3K41UU1ghDseP9QB91WAc8dATeUTN9smk1R0livD/nO1Bw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yBO5F4AgPJPLPNK7H4fH2SfT8jQvNwPOrVI8zN+F4CM=; b=Tb5VBpUbN3PtgbphDqccc9CmbhRlylnr8ec7cFRPtgdjNNcq1D2rKPIWR/c9LFAcIeeRGMyESun+ja+zLiqp20XrZKuujBAGO2xXeDUCd7Dx8hJk6+DeI5a1jtCyCn48zkaCADuJ8cNyJEa9MXKTWgSnygqhXzAHgaPuZzIRRWucH9eAfJT+3FIw1SYdoYwgOqHqBBVTkz6Fr9EGxsxDsezmT89CMBSMWZslgBLqs1BgZZEQW1wVJveYgcCgp7GLqDN2j/En1/SjlLn/wrrc28bp74gNC9cvoH7NrMYHbuxdDA3uJJuV6m4a25iOjV3xtiqKQt2k9AR+ob6lTMpogQ== Received: from MW2PR12MB2492.namprd12.prod.outlook.com (2603:10b6:907:8::19) by MWHPR12MB1343.namprd12.prod.outlook.com (2603:10b6:300:7::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.24; Thu, 25 Mar 2021 08:21:34 +0000 Received: from MW2PR12MB2492.namprd12.prod.outlook.com ([fe80::99f2:8567:2f9e:c351]) by MW2PR12MB2492.namprd12.prod.outlook.com ([fe80::99f2:8567:2f9e:c351%4]) with mapi id 15.20.3890.038; Thu, 25 Mar 2021 08:21:34 +0000 From: Matan Azrad To: "Dumitrescu, Cristian" , Li Zhang , Dekel Peled , Ori Kam , Slava Ovsiienko , Shahaf Shuler , "lironh@marvell.com" , "Singh, Jasvinder" , NBU-Contact-Thomas Monjalon , "Yigit, Ferruh" , Andrew Rybchenko , Jerin Jacob , Hemant Agrawal , Ajit Khaparde , "Richardson, Bruce" , "Doherty, Declan" CC: "dev@dpdk.org" , Raslan Darawsheh , Roni Bar Yanai Thread-Topic: [PATCH 2/2] [RFC]: ethdev: manage meter API object handles by the drivers Thread-Index: AQHXG9Tf+hxjiPtdp0KoZArVyb7r8qqSIKAAgAIvtQA= Date: Thu, 25 Mar 2021 08:21:34 +0000 Message-ID: References: <20210318085815.804896-1-lizh@nvidia.com> <20210318085815.804896-2-lizh@nvidia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=nvidia.com; x-originating-ip: [79.176.34.40] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5b3e8cea-168a-4d83-e03c-08d8ef6700d7 x-ms-traffictypediagnostic: MWHPR12MB1343: x-ld-processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zCfYrdwX0Rm0HSkQMFUas1ddaqRhYRtD8/iXWR9QVDOn5pFWC5i0//8WqnO3bXir14ZdyjFo3iU2kSYbeG0xMgoV7Br+Uuk12qMBebkr79ldRAEZ9m2XmjCtjRdKK2B9tDLsvFYtlm9UshmA+yKzyyOpyUUFx26Mw3P7WRM2qNfZVbTj4XDYkXGRQbpUyaX5pIZ7onadJcVbsJPW5hfubDRZk6MoHNO+DBVMLSb4fgzRi3vUbcFn3LEWbAsGqONgWSnpqVGKUthGDlnofsxSkuR/KfSB2N0yjMtcWvplEUcLSpCKnRvRwzWECGqLJ6E4eGEo4KHzWXH5msYdl6vnNhoM9Jlbk/3LPB17cpTyqu54KNLatCiNGTxcLpOFEBAKOPOf0bveWN1r4wC6wZ2H/0jijScxE2M5RYH7fAGaGD7SgQT+THOQqW1GP6AoXVpfmiH83zrTR2IaRqU3NafTyDkolwurN9HOeLZBj2mPX4gXrosCxnKLPV2GIMamJMWDKtxhuQLcNelvOkQfbsZ77YVL8Di6rsTRMdf1i9Ai0Omw5O2mkicN9cHDuS49A0OvwWwI+N14a1owTE8T0VnHmwCfjBhuTCeZCcIIykILXOWLuzU5JxqZB6gZZZaiyAD2FuvAUCDarWjW87+IBV+vwTcZi/4Jf+MLJUQpr+Wlh0NZAfY+c6EtcauU4cqIYIq27RtdgtTgbSWEcJb16nnb0g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW2PR12MB2492.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(39860400002)(376002)(366004)(346002)(66946007)(7416002)(64756008)(9686003)(33656002)(66446008)(66556008)(54906003)(53546011)(66476007)(76116006)(2906002)(55016002)(86362001)(83380400001)(110136005)(186003)(26005)(7696005)(6506007)(52536014)(921005)(478600001)(8676002)(45080400002)(71200400001)(107886003)(5660300002)(8936002)(4326008)(38100700001)(966005)(316002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?eR+evmlV9mWgGXJ6tsFTd2g8zFDfHae+SAfI84Ka/eXuyh5f3+68kv2NHLJj?= =?us-ascii?Q?HC8NifU593M/vvG8fyZ8FtS3qTLbj4dZEJBeIXqJI4KmmahX6iIg2906UiEE?= =?us-ascii?Q?90qkIXSIyHRktEeXB7izwwb2TC0QPNIFYwIzGM63Dwr8y2F4J3Vyf/WeEBNi?= =?us-ascii?Q?AKEG8TmJ6aQUzGrxBAUu63pHtG08hd9HGOLbA6ZJoAKGtRzsYCTj03acatmY?= =?us-ascii?Q?nSPVoPPEPrlbRpb3ZSei66UpEPp/djuyKk5b56tfQ9eg1XgOwrUZcgrFOySG?= =?us-ascii?Q?NbzEZbex0S+Sipxhj7NDYQf+9XPdjVUG75ChRSi8WNzOPmEyNHNgEex6DIQ6?= =?us-ascii?Q?xhtQNo6wIWwXnNigi13A3a1RiNJy2rUBZYizp+3kXj7dyP6QRHAAvmUnddcd?= =?us-ascii?Q?Jq85TboLqGSuWko6svz3QDHqLnDIjqWjcbxTll214NXMacYZX127fRpXxVr6?= =?us-ascii?Q?6CrJtT/5XWSQ6kH37PCFv+eZEWgf1elFb5iGtNljPlhYn5tPR8kHk2WDxEOu?= =?us-ascii?Q?1UOuGG8n6zD8+N3Q/KOvC3ohut7VHXYS28xs87kR6DMAcUfZ6tGQW8wOCLHB?= =?us-ascii?Q?f3yCaY9vgzbwBvSnsZJxXcjDq5oqHZCw1IDdOBtbSpfPG2xboh7LBOl9sZyA?= =?us-ascii?Q?Sr4z6wFETpa1OYf+Z3ggqEkESNn7xwB8RkYKsk6P+4Um1oH7O5DP3i7C9kZo?= =?us-ascii?Q?Z7at9r8IFfdHTRrLBWVVQtOsKJzdKsxkNG7B9ayNZaaJBgwCHDrLkQka74OJ?= =?us-ascii?Q?zJg4trh6yR2OtI3QRr/gqPkoMnrYSo7lWZT8PV9d9DGH1+CI2L7BuWaQNQew?= =?us-ascii?Q?PUZj04ZK71naMz7Y4GQq3mtVuomUnHeEQ/ioTkFmohnRvQRv0K4bdAfz9tgb?= =?us-ascii?Q?soGZuEFUZnKMmpigvA/orQMErbwg7WTYPjOX6twNAuj3w3b/BBGV2edrNiXB?= =?us-ascii?Q?7BZxLRI976KTF4UWFydYuhOwXZJJ3gomGSP4MHwE587fPVT+ge05TzzQzg2U?= =?us-ascii?Q?kt9e11gJycKzjAnUju18lI+msPnqRHhG9PPoDcfEKi8wS1ae+mshH/UdlXjn?= =?us-ascii?Q?11qBkVnTw+GSZgvblRXB5WK0w5iUreCodQs8anA99dpnpusmSvDE1EJphP7h?= =?us-ascii?Q?4cUSXQ+6nWagPpBOXUS12F5IGu94fRWJAf6aC93q25OZwCjehsdPZjpZEMIE?= =?us-ascii?Q?DbVLcPMZSfy+gEuXVvxVkx1PZoqB8mNsZdPmgy0COi4Oy4kKeEp5NDoNNgCU?= =?us-ascii?Q?Kes55rkNabsfCGtdeNW83RWfMGdclM/q+XTZKT4maFGQ/af202QTmXbPCyve?= =?us-ascii?Q?rL4=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW2PR12MB2492.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5b3e8cea-168a-4d83-e03c-08d8ef6700d7 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2021 08:21:34.6033 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: cP6+cfL56azBMn/f9P9KiGmgr27KO9HlqOoJ4myEKz09fNPc64WHRLF3fU0mXDyQZQ4il0hy1OVNZLmU5R0qrQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR12MB1343 Subject: Re: [dpdk-dev] [PATCH 2/2] [RFC]: ethdev: manage meter API object handles by the drivers 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 Cristian From: Dumitrescu, Cristian > Hi Li and Matan, >=20 > > -----Original Message----- > > From: Li Zhang > > Sent: Thursday, March 18, 2021 8:58 AM > > To: dekelp@nvidia.com; orika@nvidia.com; viacheslavo@nvidia.com; > > matan@nvidia.com; shahafs@nvidia.com; lironh@marvell.com; Singh, > > Jasvinder ; Thomas Monjalon > > ; Yigit, Ferruh ; Andrew > > Rybchenko ; Dumitrescu, Cristian > > > > Cc: dev@dpdk.org; rasland@nvidia.com; roniba@nvidia.com > > Subject: [PATCH 2/2] [RFC]: ethdev: manage meter API object handles by > > the drivers > > > > Currently, all the meter objects are managed by the user IDs: > > meter, profile and policy. > > Hence, each PMD should manage data-structure in order to map each API > > ID to the private PMD management structure. > > > > From the application side, it has all the picture how meter is going > > to be assigned to flows and can easily use direct mapping even when > > the meter handler is provided by the PMDs. > > > > Also, this is the approach of the rte_flow API handles: > > the flow handle and the shared action handle is provided by the PMDs. > > > > Use drivers handlers in order to manage all the meter API objects. > > >=20 > This seems to be take 2 of the discussion that we already had in this th= read: > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fmails= .dp > dk.org%2Farchives%2Fdev%2F2021- > March%2F200710.html&data=3D04%7C01%7Cmatan%40nvidia.com%7Cab0 > e3cc77b9e4101344e08d8ee434bbe%7C43083d15727340c1b7db39efd9ccc17a% > 7C0%7C0%7C637521320105450617%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000& > amp;sdata=3D94bFRICfGEzk5s53MRUvFMQe5ZlhP2Tmnu82hwUytc4%3D&re > served=3D0, so apologies for mostly summarizing my previous feedback here= . >=20 > I am against this proposal because: > 1. We already discussed this topic of user-provided handles vs. driver-pr= ovided > handles at length on this exact email list back in 2017, when we first in= troduced > this API, and I don't see any real reason to revisit the decision we took= then. Why not? There is more experiences\usages now. New drivers added the support and also now scalability is growing and growi= ng.... > 2. For me, it is more natural and it also helps the application to simpli= fy its data > structures if the user provides its own IDs rather than the user having t= o deal > with the IDs provided by the driver. Generally I don't think other flow DPDK APIs align with your feelings here,= see rte_flow object and rte_flow_shared_action. Specifically for meter: - here, meter is HW\driver offload where performance\rate either for meter= creation\deletion or for the actual data-path is very important especially= when we talk on very big numbers, so "natural" has less importance here. We need to think on the global solution for application ->API->driver. i= n meter feature, the user has the ability to manage the IDs better than the= PMDs for the most of the use-cases: 1. meter per flow: just save the driver handle in the app flow context. 2. meter per VM\USER flows\rte_flow group\any other context grouped mult= iple flows: just save the driver handle in the app context. If PMD need to map the IDs, it is more complex for sure, requires more mem= ory and more lookup time. - I'm not sure it is natural for all the use-cases, sometimes generating u= nique ID may complex the app. > 3. It is much easier and portable to pass numeric and string-based IDs ar= ound > (e.g. between processes) as opposed to pointer-based IDs, as pointers are= only > valid in one address space and not in others. There are several DPDK APIs= that > moved away from pointer handles to string IDs. Yes, I agree here generally. But again, since meter is used only by rte_flow, it is better to align the = same handle mechanism. > 4. The mapping of user IDs to internal pointers within the driver is IMO = not a > big issue in terms of memory footprint or API call rate. Matan also confi= rmed > this in the above thread when saying tis is not about either driver memor= y > footprint or API call speed, as this mapping is easy to optimize. Yes, it is not very big deal, but still costs more than the new suggestion,= especially in big scale. > And last but not least, this change obviously propagates in every API fun= ction, > so it would result in big churn in API, all drivers and all apps (includi= ng testpmd, > etc) implementing it (for IMO no real benefit). Yes, this API is experime= ntal and > therefore we can operate changes in it, but I'd rather see incremental an= d > converging improvements rather than this. Yes, it changes all API, but very small part in each, will be very easy to = align all the current dpdk components to use this concept.=20 > If you guys insist with this proposal, I would like to get more opinions = from > other vendors and contributors from within our DPDK community. Yes, more opinions are very welcomed. Thanks