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 8F756A054F; Tue, 2 Mar 2021 02:46:53 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4BEE44014E; Tue, 2 Mar 2021 02:46:53 +0100 (CET) Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) by mails.dpdk.org (Postfix) with ESMTP id 5482C40142 for ; Tue, 2 Mar 2021 02:46:51 +0100 (CET) Received: by mail-qt1-f171.google.com with SMTP id r24so13672701qtt.8 for ; Mon, 01 Mar 2021 17:46:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8fwmu9/UDr2DfJp1IGX5qYV9DF5JD5/H5HA9R2h4RPI=; b=UQwyctEA45HHNUdFKPs1+LkaFH9ZXCB1kUJw+7BuEP1kGCrft17rL/wQ9gPUPV4MHo B3PjC8h8QczTR7rCFtMivR9/48ztP3WL2V693UAi1V+xwYY4tSfhU1qJdMfVM67/OTnY Ful3WM9BJIT1sX8UO2l+jVw3pSCM45ficMdrU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8fwmu9/UDr2DfJp1IGX5qYV9DF5JD5/H5HA9R2h4RPI=; b=I+zdObyue1dk8ubeM/0bZc7w4BBoAEkz9ZraI6dQFhPYz+9buJJjbRCm4CxIFfmFsa 2vlt9EDGDqrxnGMwKOSAeKO3WPg/qpdlbSiW6/IPBebdYxqem+PE6UPPVtSjYvF8Z2G4 Kdr26/DeGvBWwXZeB42EXe3sA3tI0KYGXbiP/s9qchWn9SLQCnzpYX2cpNXDeOJ0O/dk BQgcgeVpg2IIlP8zMEzbzDp0wRAP54ffhr0+ma07RgYAn+Jn2Xs+qgrtBJvq4TGyOkjJ ROOVFfBmbvoD+DI4shQG+kgOfzRnQIgAJ0iuX2dkRMYhUwEwswZwf36kdqWYKuZehHj2 MVMA== X-Gm-Message-State: AOAM530fy7CAV3lfuGSw5xJFFHdMi9CWTabUGl73WtM/Hiuboa9CzaZg 0hcX9uRWbNNE49f2YLAUZV7/eaZQ4xuDRLYV9r/s8w== X-Google-Smtp-Source: ABdhPJyFtFuWe8bcso6X5//LhX3dfxzQoRpEzIefmXoDSftlg8xoLOBzp9FqeUXVGBbWQkhjmXEQTqE2WGHrElG5/Ag= X-Received: by 2002:a05:622a:28b:: with SMTP id z11mr16143844qtw.225.1614649610564; Mon, 01 Mar 2021 17:46:50 -0800 (PST) MIME-Version: 1.0 References: <20210125010235.1768333-1-lizh@nvidia.com> <20210301103532.184983-1-lizh@nvidia.com> <20210301103532.184983-2-lizh@nvidia.com> In-Reply-To: From: Ajit Khaparde Date: Mon, 1 Mar 2021 17:46:34 -0800 Message-ID: To: "Dumitrescu, Cristian" Cc: Li Zhang , "dekelp@nvidia.com" , "orika@nvidia.com" , "viacheslavo@nvidia.com" , "matan@nvidia.com" , "dev@dpdk.org" , "thomas@monjalon.net" , "rasland@nvidia.com" , "mb@smartsharesystems.com" , "Yigit, Ferruh" , "Singh, Jasvinder" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000007f9e9905bc83e81b" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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" --0000000000007f9e9905bc83e81b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 1, 2021 at 5:20 AM Dumitrescu, Cristian wrote: > > > -----Original Message----- > > From: dev On Behalf Of Li Zhang > > Sent: Monday, March 1, 2021 10:35 AM > > To: dekelp@nvidia.com; orika@nvidia.com; viacheslavo@nvidia.com; > > matan@nvidia.com > > Cc: dev@dpdk.org; thomas@monjalon.net; rasland@nvidia.com; > > mb@smartsharesystems.com; ajit.khaparde@broadcom.com > > Subject: [dpdk-dev] [RFC v4 1/4] ethdev: add meter PPS profile > > > > Currently meter algorithms only supports rate is bytes per second(BPS). > > Add this new meter srTCMp algorithm to support rate is packet per secon= d. > > So that it can meter traffic by packet per second. > > The below structure will be extended: > > rte_mtr_algorithm > > rte_mtr_meter_profile > > Signed-off-by: Li Zhang > > --- > > .../traffic_metering_and_policing.rst | 3 +- > > doc/guides/rel_notes/release_20_11.rst | 5 +++ > > lib/librte_ethdev/rte_mtr.h | 32 +++++++++++++++++++ > > 3 files changed, 39 insertions(+), 1 deletion(-) > > > > diff --git a/doc/guides/prog_guide/traffic_metering_and_policing.rst > > b/doc/guides/prog_guide/traffic_metering_and_policing.rst > > index 90c781eb1d..4d2405d44a 100644 > > --- a/doc/guides/prog_guide/traffic_metering_and_policing.rst > > +++ b/doc/guides/prog_guide/traffic_metering_and_policing.rst > > @@ -17,7 +17,8 @@ The main features are: > > * Part of DPDK rte_ethdev API > > * Capability query API > > * Metering algorithms: RFC 2697 Single Rate Three Color Marker (srTCM)= , > > RFC 2698 > > - and RFC 4115 Two Rate Three Color Marker (trTCM) > > + and RFC 4115 Two Rate Three Color Marker (trTCM), > > + Single Rate Three Color Marker, Packet based (srTCMp). > > * Policer actions (per meter output color): recolor, drop > > * Statistics (per policer output color) > > > > diff --git a/doc/guides/rel_notes/release_20_11.rst > > b/doc/guides/rel_notes/release_20_11.rst > > index 7405a9864f..de04886cc9 100644 > > --- a/doc/guides/rel_notes/release_20_11.rst > > +++ b/doc/guides/rel_notes/release_20_11.rst > > @@ -429,6 +429,11 @@ New Features > > can leverage IOAT DMA channels with vhost asynchronous APIs. > > See the :doc:`../sample_app_ug/vhost` for more details. > > > > +* **Added support for meter PPS profile.** > > + > > + Currently meter algorithms only supports bytes per second(BPS). > > + Add this new meter algorithm to support packet per second (PPS) mode= . > > + So that it can meter traffic by packet per second. > > > > Removed Items > > ------------- > > diff --git a/lib/librte_ethdev/rte_mtr.h b/lib/librte_ethdev/rte_mtr.h > > index 916a09c5c3..f27a4b5354 100644 > > --- a/lib/librte_ethdev/rte_mtr.h > > +++ b/lib/librte_ethdev/rte_mtr.h > > @@ -119,6 +119,11 @@ enum rte_mtr_algorithm { > > > > /** Two Rate Three Color Marker (trTCM) - IETF RFC 4115. */ > > RTE_MTR_TRTCM_RFC4115, > > + > > + /** Single Rate Three Color Marker, Packet based (srTCMp). > > + * - - similar to IETF RFC 2697 but rate is packet per second. > > + */ > > + RTE_MTR_SRTCMP, > > }; > > > > /** > > @@ -171,6 +176,20 @@ struct rte_mtr_meter_profile { > > /** Excess Burst Size (EBS) (bytes). */ > > uint64_t ebs; > > } trtcm_rfc4115; > > + > > + /** Items only valid when *alg* is set to srTCMp. */ > > + struct { > > + /** Committed Information Rate (CIR) > > + * (packets/second). > > + */ > > + uint64_t cir; > > + > > + /** Committed Burst Size (CBS) (packets). */ > > + uint64_t cbs; > > + > > + /** Excess Burst Size (EBS) (packets). */ > > + uint64_t ebs; > > + } srtcmp; > > }; > > }; > > > > @@ -317,6 +336,13 @@ struct rte_mtr_capabilities { > > */ > > uint32_t meter_trtcm_rfc4115_n_max; > > > > + /** Maximum number of MTR objects that can have their meter > > configured > > + * to run the srTCMp algorithm. The value of 0 > > + * indicates this metering algorithm is not supported. > > + * The maximum value is *n_max*. > > + */ > > + uint32_t meter_srtcmp_n_max; > > + > > /** Maximum traffic rate that can be metered by a single MTR > > object. For > > * srTCM RFC 2697, this is the maximum CIR rate. For trTCM RFC 26= 98, > > * this is the maximum PIR rate. For trTCM RFC 4115, this is the > > maximum > > @@ -342,6 +368,12 @@ struct rte_mtr_capabilities { > > */ > > int color_aware_trtcm_rfc4115_supported; > > > > + /** > > + * When non-zero, it indicates that color aware mode is supported > > for > > + * the srTCMp metering algorithm. > > + */ > > + int color_aware_srtcmp_supported; > > + > > /** When non-zero, it indicates that the policer packet recolor > > actions > > * are supported. > > * @see enum rte_mtr_policer_action > > -- > > 2.21.0 > > Hi Li, > > As specified in the MAINTEINERS file of DPDK, I am the maintainer of this= API, so please make sure you add my email in the To: list of future revisi= ons of this patch set. > > Isn't this a duplicate of this other patchset that you authored as well: = http://patchwork.dpdk.org/project/dpdk/patch/20210301094000.183002-2-lizh@n= vidia.com/ ? Which one do you want to keep? I am pasting below my reply to = this other patchset. > > 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 exist= ing 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 differ= ent 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 p= rofile. When packet_mode is 0, the profile rates and bucket sizes are speci= fied 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 p= er second, respectively. The same profile parameters are used, no need to i= nvent additional algorithms (such as srTCM - packet mode) or profile data s= tructures. Can we do the same here, please? > > This is a quick summary of the required API changes to add support for th= e packet mode, they are minimal: > a) Introduce the packet_mode flag in the profile parameters data structur= e. > b) Change the description (comment) of the rate and bucket size parameter= s in the meter profile parameters data structures to reflect that their val= ues represents either bytes or packets, depending on the value of the new f= lag 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 capabili= ties, when applicable. Overall I think this is a better approach. And default packet_mode will be bytes. > > Regards, > Cristian --0000000000007f9e9905bc83e81b--