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 ECE10A054F; Tue, 2 Mar 2021 19:10:49 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 76F5A22A2A2; Tue, 2 Mar 2021 19:10:47 +0100 (CET) Received: from hqnvemgate24.nvidia.com (hqnvemgate24.nvidia.com [216.228.121.143]) by mails.dpdk.org (Postfix) with ESMTP id 2EB364014E for ; Tue, 2 Mar 2021 19:10:45 +0100 (CET) Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate24.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Tue, 02 Mar 2021 10:10:45 -0800 Received: from HQMAIL105.nvidia.com ([172.20.161.6]) by hqpgpgate101.nvidia.com (PGP Universal service); Tue, 02 Mar 2021 10:10:45 -0800 X-PGP-Universal: processed; by hqpgpgate101.nvidia.com on Tue, 02 Mar 2021 10:10:45 -0800 Received: from HKMAIL102.nvidia.com (10.18.16.11) by HQMAIL105.nvidia.com (172.20.187.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 2 Mar 2021 18:10:43 +0000 Received: from HKMAIL104.nvidia.com (10.18.16.13) by HKMAIL102.nvidia.com (10.18.16.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 2 Mar 2021 18:10:08 +0000 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.102) by HKMAIL104.nvidia.com (10.18.16.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 2 Mar 2021 18:10:07 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SYAT0uaOzTAMVAtjRUm6fshhM0976aMiCub/NybqDCwHAYTvNtTLMSR0n6a4thDZnhUfcMGoNgzK7E17h+/EPbJHVcJcaefdyMKubMLXdGlOqSSV2SDPCMFPq5LoDlg7Sjso+PyHx+cCC4P/5FbbDBryCHh5NE+Ue8OOL85Pa3HNh/ZqQqPkF+GQtL4l9SouWxzIeJO92UVZpq7vBOp2aKPs2fEimmDp0A/vrl7ke/NYfEN0ZYkFKbHr2dD1FsJB59roVrQDcqqQf0rsZzaYNNEftbFKxrcq4DCtU3DmE9FLzBxu0bl3+Wj9Og4FhKpxc2tsRRcRiNpHg7TzJqVyww== 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=TxSr+eraVuqk0zrvCR/UD3xX0VIS+hKsT4WFgwKtF5w=; b=Kr6Dtq5JfOM2YX4cEeyD2aWxey1lLqM9taDLGM5IuvjX1Znw/wjVaLeDWcOEh7hE8gH2J+oy8/IdRCf7gGPFCmW969zCSz151/GT2uaY20cz7qMWvtdFPp61Q6kMuUsy5bWIfed2fVuOTHLQ9oWzMa6sqgeXjwHoB7PVYqOdGBpuSg5aVnfAkh4xTRQmeJujdgnMPNancjS/rSI0KeHb61e8GLRk+vGsPHrjPNyWdqK2yhY4aUBlOgzVRIMN5fDk0N4gDkGJ3a7G8UZAwrqTOOwxojsHLn5/B0t21Z8Hv0kg7t9gb9XtQfOBNs8SVKmgJyqcSpppWGE04UFgvGGiGg== 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 Received: from MW2PR12MB2492.namprd12.prod.outlook.com (2603:10b6:907:8::19) by MWHPR1201MB0079.namprd12.prod.outlook.com (2603:10b6:301:52::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.17; Tue, 2 Mar 2021 18:10:04 +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.028; Tue, 2 Mar 2021 18:10:04 +0000 From: Matan Azrad 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" Thread-Topic: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile Thread-Index: AQHXDoaku6PLW53KtUOtQaDT1ovmy6pvHh4AgAEiL2CAAGH8AIAAAHAwgAAiHQCAADFYsA== Date: Tue, 2 Mar 2021 18:10:04 +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: 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: [216.228.117.191] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f9ecd750-c084-45da-3de1-08d8dda667b9 x-ms-traffictypediagnostic: MWHPR1201MB0079: x-ld-processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-header: ProcessedBy-CMR-outbound x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2unv1Sn/WEsm1doEDE8xw1wLelf1CPbU3DYlJZPAlQj4NZwHGwzqiQ/vrKLhminGcVfPJRpM0devVR/OhnU0QnsEWx6ISU7OSBLHu7fFpfmBj9S9zsKsAHHTLuDe9bN2p5Rk/ycDguumdJLz6zy7jb+Lm1UWcTcEoyDFyoyQOb/PzegjtMMo5HNgL6evadlWpo/nfRTYHJevnBAuZbRP+AIBXUAKs6dtmpKYbd2Ux2KJ0SDxPapiYZsxFiX1KyVNAw5d+jyqq9z6vst5joB4LkM+hE5zDWTfpmb3rtJyGp5bPZI9xAQpDlXpXNRo+1YhxhL/pbeHQDUuwX28TMgiHHRb+NRztvMh09glmWC6R3OMwLpP5Sz3hjVqGGKrhgai7NMEU5XlO0rUsz8vvun+UsVq0LSIkRxrVq3CLlE0oUiSrudjw7FV5vj02R21wCIR4c7VMDTRY9kJQCKcPluEdgp3jd5WTZ68Swt/yNNwgZUcsLAnZZ6uMDEbahOWFEy5UkJDc9VBYuAFzf1+nZJKhw== 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)(366004)(39860400002)(346002)(376002)(5660300002)(6506007)(2906002)(55016002)(186003)(6636002)(83380400001)(52536014)(9686003)(33656002)(76116006)(53546011)(71200400001)(26005)(110136005)(4326008)(7696005)(64756008)(66446008)(54906003)(8676002)(316002)(66556008)(86362001)(8936002)(478600001)(66946007)(66476007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?D/SCIuynLeVYN9RMrQkwrHPykDY7Hm2S2mQFUtTakDAQOjGjcN08mp5SlH/E?= =?us-ascii?Q?2sm+N/el3tL/MgqAzuurVa42dW2sOVhJ/DpuBx6CCHy/cXyyAsy46BPR3oF9?= =?us-ascii?Q?XpkBVDU6np9FDJstH1A7j1RCh2xc1CmaehLe1ghNvG/RRjUKbO8YiesAGZrU?= =?us-ascii?Q?BGYam91uaTX1X/Ylwm0kg3Pj1kRgZVJ3e6929iTbcLUkvnbEr+eboyVVKO3m?= =?us-ascii?Q?TkTWn9EE8g9CT5sh6F6t6Cp5ZD2FBu7CLqDHldLb3FxuJlzENqX5CqZdkiqW?= =?us-ascii?Q?XsaD4RztCGjFStDg+mVWXSsMhXGVcWQXVoBtc5QxxPGdzSP9v+HwJxF4i8q2?= =?us-ascii?Q?rMKudKAGnN+ahgZG2ogwZnk9HEyNvwAZQbb/kksaFf0F1MqnuUEXByFC9/vJ?= =?us-ascii?Q?wpx9v/3aSMCEnLYkygHmqKWajzyMSjxwzNxPLDRK4LFiJAEXX4xhdZcv6sbV?= =?us-ascii?Q?4EsvzA+qoQsJEWTL5/0q+sCetYzI6KzVCsNJjAS/8/44XFwy7P4NldabFIrz?= =?us-ascii?Q?TTFyLwNdqixGuTBf1o6Q5yWNaYAoaFY8vL5pJVZArv8soTBo8YmdpqPTah6F?= =?us-ascii?Q?4qcckQf3aZo/oc4CqIiwIfP532NbvBZs0jojrL/GrjCObQYdOitVUK5rl9i7?= =?us-ascii?Q?j7p/WrRflJIpNd5hlyMpUn72rQsAKrNrA061W0b3TFriI1j3axfmcVN2ETTs?= =?us-ascii?Q?uJRJ/XqzlO2UwerLSvHPQpdqeHT8Epk3ZNsy2uIyJpVO3ULuR5R/7/NWCX7q?= =?us-ascii?Q?B330kbQjLzK+d9X/m+tYZgN1W4ek9HvqXZ3AvsqZb19JEfCfOjLaO31FhHx6?= =?us-ascii?Q?2PvlkLiCwf7YECyRa6y3bNQZZZPYDXP6XZ8FHAWjLS4tTOzlmKshzn8Ukgo/?= =?us-ascii?Q?jMDh/ZmjJ7DQU0l642XxxryLCOSZmJLxjcaasUomh/2/bY+BToN1hpZBpcbF?= =?us-ascii?Q?HkRNpeR/S1cdSXG1oB+qc76l2Z/S6gRbltFem+H+zBIDRDqxKUgCys6jnp49?= =?us-ascii?Q?JIbH75jln69Yrx/c/NNxGnOQfEDoJ8tPxDZft4SuUeaWVFEfXwY7ciB1j/w6?= =?us-ascii?Q?ZWFbg7XS413W2xuXczqMDahMNgi4S6m2tBu86dYn/gowqxBvGGPrqcoT3duR?= =?us-ascii?Q?iUlTB6nuNvNn/1i3APdAsAOO261g71b0c7kmYFDHVh3npBQ3lNadVEuTOhl8?= =?us-ascii?Q?BCXNS59K3N+RPwCMZN0//4YTMrLFCFotOsU5TpiXkSLWYVOPN0qrqvarVC4C?= =?us-ascii?Q?RusBNituqJK0t0GaCWprS94r1aXEv1C+gWybcL7Rdv6SgNaaP9RPEVREBbIQ?= =?us-ascii?Q?lNvRGFcNmwu66eQGFd+zaqzT?= 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: MW2PR12MB2492.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f9ecd750-c084-45da-3de1-08d8dda667b9 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2021 18:10:04.5259 (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: lTEKWCm1hGkyLBldETOlffX0sRTBbozRX7JKDe9+sDX/QTlteH70MJoytLTyXFmQWgVJ1SKBmhtQTTndXoNubQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1201MB0079 X-OriginatorOrg: Nvidia.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1614708645; bh=TxSr+eraVuqk0zrvCR/UD3xX0VIS+hKsT4WFgwKtF5w=; h=X-PGP-Universal:ARC-Seal:ARC-Message-Signature: ARC-Authentication-Results:From:To:CC:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:authentication-results:x-originating-ip: x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-ms-traffictypediagnostic:x-ld-processed: x-ms-exchange-transport-forked:x-microsoft-antispam-prvs:x-header: x-ms-oob-tlc-oobclassifiers:x-ms-exchange-senderadcheck: x-microsoft-antispam:x-microsoft-antispam-message-info: x-forefront-antispam-report:x-ms-exchange-antispam-messagedata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-AuthAs: X-MS-Exchange-CrossTenant-AuthSource: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped:X-OriginatorOrg; b=n+a8Es2xxyFSy7jiYhtK8YxhZNkqNU6wPiUlRfugHL8xVJ/owwVriXJS5un07zF6l Gb+euKsdtydm41BVu3FXQdFk8lHxMwoLR6CLXdapZtu2iTNtgsbVo/FdgT0ko0Y0bh in3L/lSF+BrvYyKi2rbSujIcJffIMi4ieJRC5V3NpLnEVlrLWuPgKopDzpbk5b8SuV 3GzOlIH7KoxZ4bvCEgiAZ+woBrTfPbxjel8CLj92rvuu2R3Q/p2FTcDyHoxT5DaSen 9/y1XfSYZAgTQPja9v+uF1nSo/eTzyfQbiPN4FfVdOCPyxLu8p2pgEpr630nFvJ2M7 GthMHfRpzVh6Q== 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 Cristian Good discussion, thank you for that! From: Dumitrescu, Cristian > Hi Matan, >=20 > > -----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 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 > > > > > > > > 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 advantag= es. > > > > > > > > The main problem with the flag approach is that it breaks ABI and A= PI. > > > > The profile structure size is changed due to a new field - ABI brea= kage. > > > > 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 correctly > > > 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 uses > > it for a long time. > > Forcing them to change while we have good solution that don't force > > it, looks me problematic. > > >=20 > Not really, only 3 drivers are currently implementing this API. The user is not the PMD, the PMDs are the providers. I'm talking about all our customers, all the current DPDK based application= s 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 exi= sting > 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 places= as this > structure is initialized to all-zeros. Are you sure all the world initialize the struct to 0? and also in this cas= e, without new compilation, not all the struct will be zeroes(the old size = is smaller).=20 > A simple search exercise for struct rte_mtr_meter_profile is all that is = needed. > You also agreed the flag approach is very intuitive, hence better and nic= er, with > no additional work needed for you, so why not do it? Do you understand that any current application that use the meter API must = recompile the code of the application? Part of them also probably need to s= et the flag to 0.... Do you understand also the potential issues for the applications which are = not aware to the change? Debug time, etc.... > > > > 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. >=20 > I really disagree. As API maintainer, making every effort to keep the API= s clear > and consistent is a critical task for me. New pps profile is also clear and simple. > We don't want to proliferate the API > data structures and parameters if there is a good way to avoid it. Especi= ally in > cases like this, when the drivers are just beginning to pick up this (sti= ll > experimental) API, we have the rare chance to make things right and ther= efore > we should do it. Please also keep in mind that, as more feature are added= to > the API, small corner cuts like this one that might not look like a big d= eal now, > eventually come back as unnecessary complexity in the drivers themselves. I don't see a complexity in the current suggestion. > So, please, let's try to keep the quality of the APIs high. Also by this way is high. 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 all = understand the pros and cons. If you understand my concern on flag approach and still insist to take the = flag approach we will align. And if we so, and we are going to break the API\ABI, we are going to introd= uce new meter policy API soon and there, breaking API can help, lets see in= other discussion later. One more point: Currently, the meter_id is managed by the user, I think it is better to let= the PMDs to manage the meter_id. Searching the PMD meter handler inside the PMD is very expensive for the AP= I call rate when the meter_id is managed by the user. Same for profile_id. Also all the rte_flow API including the shared action API taking the PMD ma= nagement approach. What do you think? > > > 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 data > > > > 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 >=20 > Regards, > Cristian