From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 516C6A0577; Tue, 7 Apr 2020 18:31:58 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 96B582B96; Tue, 7 Apr 2020 18:31:57 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id E1EF3FFA for ; Tue, 7 Apr 2020 18:31:55 +0200 (CEST) IronPort-SDR: M6wxnlT2p+mdRPeogOxLKbEVu6ORNafxgXpnfVXA2/5YrSyAN2ClcVwnBPQKdBDdTWcg+DQsaO 9lQ3ZQoLf7OA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Apr 2020 09:31:55 -0700 IronPort-SDR: I5UT1UEM4mnHSt0UM3Vt79ID5+xirkPJ3McLwB1hK9oVQTvuwrHo3XPKlF0S6pU5cFsYYvaAwx X5R8KU9ELG0Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,355,1580803200"; d="scan'208";a="361581825" Received: from orsmsx104.amr.corp.intel.com ([10.22.225.131]) by fmsmga001.fm.intel.com with ESMTP; 07 Apr 2020 09:31:54 -0700 Received: from orsmsx601.amr.corp.intel.com (10.22.229.14) by ORSMSX104.amr.corp.intel.com (10.22.225.131) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 7 Apr 2020 09:31:54 -0700 Received: from orsmsx609.amr.corp.intel.com (10.22.229.22) by ORSMSX601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 7 Apr 2020 09:31:53 -0700 Received: from ORSEDG001.ED.cps.intel.com (10.7.248.4) by orsmsx609.amr.corp.intel.com (10.22.229.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Tue, 7 Apr 2020 09:31:53 -0700 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.170) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 7 Apr 2020 09:31:53 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OIdHlPrRP1AhBh3CcIXjzyXwqgzBs18JMAY4XwDpRpbDxgq2YFN8XIzOYLiSeL4KymYoSfXWRjQK+HSoXY2M9VaQXgzjhKi3xN+Kpm/lSvRc1T8AI6CX0kgS4B4uh4WkKDJVpA8Jc/Rx3mSdF11owB6/ExJDdoAszT0/X2Hy0q2qypYrOucfYBJyP9Ki9HytbfcRZWVN4Ibbd1MBalDYYgS/vIbf4tKk3aUTvalhS1clTdkqhcj+qnHr6VrOhgdneueT7eQGuWBVnbZ83MjoEyjb0RL3kIUmGg29Jt7IPmkU3bos03L2SFPE2WqXs7opxyVCrBCFrzlkmLsKRAvwZw== 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=WdZG2pPKO+TZnxfRxe1DqFCoj0QPl3NY1JQPbQxejQ4=; b=J7lIZaetFNSxgkOkb4i9Hn1vy4LEVxGhDn+D8qUH3doqsAjcaTy1AUZF/z+bRS4QdAnBNqNFNEVK6OYiV52M5UNqHPbff9wZoHSS1Zr5VxgYj38oVzCtZFafs6w6YXs8D45oaPBhjJc6bAdaBvmKeHLRQiKB/iNUEmgQzu5ZErySLaaeBiPaU2j/Jz7T/RrUZwZ/smoQXrXctpOXM+kSqHO6PfUIxNjC33OibRSqGiKYIfHw2HWkeN1n1ff3ta5eO8H60zw/VnA56ZxXYIHemVDMsBdlKJZRD3Em5IV3c460wpT7B5dYxc1L7dmvHr9lryoR9xCjaHMwPTDIDqG3fg== 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=WdZG2pPKO+TZnxfRxe1DqFCoj0QPl3NY1JQPbQxejQ4=; b=iynGe1iQrOmkrJSp4iY1QjPI6nnrNWKCWZsmgOivEhp1FiocwWMgiO3F2dSkAeVRftVHIDwAygbdVhBzl3oGf+BDTOc50HzBigUeHqKfwpIRdC84vVTpkuDSHziPg4bpp0na2ZZYBfQaHZeEIfv7QehvJWINl30sZ8Ntfdk0L8s= Received: from BYAPR11MB2935.namprd11.prod.outlook.com (2603:10b6:a03:82::24) by BYAPR11MB3480.namprd11.prod.outlook.com (2603:10b6:a03:79::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.20; Tue, 7 Apr 2020 16:31:47 +0000 Received: from BYAPR11MB2935.namprd11.prod.outlook.com ([fe80::786e:a42b:df03:a829]) by BYAPR11MB2935.namprd11.prod.outlook.com ([fe80::786e:a42b:df03:a829%5]) with mapi id 15.20.2878.021; Tue, 7 Apr 2020 16:31:47 +0000 From: "Dumitrescu, Cristian" To: Nithin Dabilpuram , Thomas Monjalon , "Yigit, Ferruh" , "Andrew Rybchenko" CC: "dev@dpdk.org" , "jerinj@marvell.com" , "kkanas@marvell.com" Thread-Topic: [PATCH 1/2] ethdev: add tm cap for private shaper packet mode Thread-Index: AQHWBqyvHJ/9k4iRG0Go4EWnkPq7Q6ht2WbA Date: Tue, 7 Apr 2020 16:31:47 +0000 Message-ID: References: <20200330160019.29674-1-ndabilpuram@marvell.com> In-Reply-To: <20200330160019.29674-1-ndabilpuram@marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.2.0.6 dlp-reaction: no-action dlp-product: dlpe-windows authentication-results: spf=none (sender IP is ) smtp.mailfrom=cristian.dumitrescu@intel.com; x-originating-ip: [192.198.151.160] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 220db093-143a-4a7c-abcc-08d7db112aeb x-ms-traffictypediagnostic: BYAPR11MB3480: 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-forefront-prvs: 036614DD9C x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2935.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(39860400002)(376002)(396003)(346002)(366004)(136003)(66946007)(478600001)(110136005)(186003)(55016002)(64756008)(5660300002)(66476007)(71200400001)(52536014)(4326008)(66556008)(66446008)(9686003)(81156014)(53546011)(6506007)(33656002)(2906002)(7696005)(26005)(8676002)(81166006)(8936002)(316002)(54906003)(76116006)(86362001)(290074003); DIR:OUT; SFP:1102; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: llQ82pupD4VNCuYmC56abOhnbhSjkYN44RlS0wR7EpS7X5gZa72ibLAtZfWSvqKk8MxNhqHwF2YyINbn+pgwoDoGOkQkxiwY2hyCGXZjrwogMcSTWKdHCAUdgieQ9jXDaYivLopDlOIpZA92m5IUUi6Tm9rK67iM1xHYSXW7oD2dCjzlZgCATN0i4vpq+egcwiwBFSsr4lTHM2MBWQGO/gEIb0DbAAfzckBtaz9uXyUMVHZmiotxWjCJubwHsT1SfxI+eR6wI0+JBxvrxcqdSOt7mKZ/E4i2x12Hrka252asYwpJ6bsyXuSHBp/mqS+Vg6mHnH4w2m7aBcuuHi6j2vv+kYg0qcokOUm2FD4qwmC4uWuPiu1n2D6S6jBqG6hj/bEUz9ISr0+zt1obffXr94fqA9JEiMzIVdt+yt/3znFvLNivOycu4oMO0iivTyKfUrT+8dEW3Xh75y2p6V9PZ6XgVPGhjxiRs1at2x2he52IjQa0mlozX0IFJv3ZVZIc x-ms-exchange-antispam-messagedata: 7OaDN75qhlgWhtnO98t80pBsDCxtdCRXfKVVTatndCJUN2p5Ztb+9y32k31aH4PvI7EGX4IJPhoNaaJ9nyngu4BWyOaH0h2PlS1dTv7urGljAk/SzU2V6MHKoW7vnDi7nX1IltKlrE2xyX087gQfVg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 220db093-143a-4a7c-abcc-08d7db112aeb X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2020 16:31:47.5400 (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: KFXEeiioTv4C7l9b2H2SWFXIQxM3fFHAutFlgnnP1U/bQC5hdEkGTDpM1NS4O7MdcM4rzK0xb6Xdi3z5g8qTJ1g/0WYv9qi+1hZpsbL5c/k= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3480 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH 1/2] ethdev: add tm cap for private shaper packet mode X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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 Nithin, > -----Original Message----- > From: Nithin Dabilpuram > Sent: Monday, March 30, 2020 5:00 PM > To: Dumitrescu, Cristian ; Thomas Monjalon > ; Yigit, Ferruh ; Andrew > Rybchenko > Cc: dev@dpdk.org; jerinj@marvell.com; kkanas@marvell.com; Nithin > Dabilpuram > Subject: [PATCH 1/2] ethdev: add tm cap for private shaper packet mode >=20 > Some NIC hardware have private shaper attached to > every node and has a limitation where packet mode is applied > both to the scheduling of a node's children using WFQ and > shaping of traffic out of the private shaper. > This cannot be expressed using existing capabilities or configurations. >=20 > So this patch adds a tm capability that if set by a PMD implies that > packet mode when configured is even applied to private shaper > connected to that node. This also implies the limitation > that all the SP children of that node should have same mode > at any point of time i.e either packet mode or byte mode and > same applies to private shaper in that NIC PMD. >=20 > This patch also adds missing capability that tells whether PMD > supports wfq weight mode or not. >=20 > Signed-off-by: Nithin Dabilpuram > --- > lib/librte_ethdev/rte_tm.h | 62 > +++++++++++++++++++++++++++++++++++++++++++--- > 1 file changed, 59 insertions(+), 3 deletions(-) >=20 > diff --git a/lib/librte_ethdev/rte_tm.h b/lib/librte_ethdev/rte_tm.h > index f9c0cf3..50bcea6 100644 > --- a/lib/librte_ethdev/rte_tm.h > +++ b/lib/librte_ethdev/rte_tm.h > @@ -339,6 +339,20 @@ struct rte_tm_capabilities { > */ > uint32_t sched_wfq_weight_max; >=20 > + /** WFQ weight mode supported. Non-zero value indicates wfq > weight mode > + * is supported and a SP child (even a wfq group) can be configured > to > + * use packet-mode or byte-mode for weight calculations. > + */ > + int sched_wfq_weight_mode_supported; > + This is incorrect, as the WFQ support, including the weight aspect of WFQ, = is already part of the existing set of capabilities: see sched_wfq_weight_m= ax and the other sched_wfq_* capability fields. > + /** Private shaper and scheduler weight mode. > + * When non-zero value indicates that all SP children should have > + * same weight mode and the same mode applies to private > + * shaper as well. This is only valid if > + * *sched_wfq_weight_mode_supported* is set. > + */ > + int sched_shaper_private_weight_mode; > + If I understand your intention correctly, you are trying to introduce packe= t mode (in addition to the existing byte mode) for (1) scheduler WFQ weight= s and for (2) shaper rates. Basically, the ability to express WFQ weights i= n bytes as well as packets, and the ability to express shaper rates in byte= s and well as packets. Is this correct? Assuming yes, we probably need to do it in a slightly different way: 1/ Similar to the WRED packet mode that was introduced by Nikhil Rao's patc= hes a while ago (in addition to WRED's byte mode), see WRED capability and = configuration. 2/ Decouple between scheduler and shaper. So we should add sched_* fields a= nd shaper_* fields, but never sched_shaper_*, as it creates a functional de= pendency that does not exist. In line with methodology already used for WRED, I suggest: a) Scheduler WFQ capabilities (TM/level/node): sched_wfq_packet_mode_suppor= ted, sched_wfq_byte_mode_supported b) Shaper capabilities (TM/level/node): shaper_rate_packet_mode_supported, = shaper_rate_byte_mode_supported. c) Shaper profile (struct rte_tm_shaper_params): add an integer packet_mode= flag with 0 =3D byte-mode (default) and 1 =3D packet mode for the values i= n struct rte_tm_token_bucket. It is important to note that the API must allow a combination of packet mod= e and byte mode (for different nodes, not for the same), but an implementat= ion can support either a single mode or both (should be enforced by the dri= ver). > /** WRED packet mode support. When non-zero, this parameter > indicates > * that there is at least one leaf node that supports the WRED packet > * mode, which might not be true for all the leaf nodes. In packet > @@ -554,6 +568,21 @@ struct rte_tm_level_capabilities { > */ > uint32_t sched_wfq_weight_max; >=20 > + /** WFQ weight mode supported. Non-zero value > indicates > + * wfq weight mode is supported and a SP child > + * (even a wfq group) can be configured to use > + * packet-mode or byte-mode for weight > calculations. > + */ > + int sched_wfq_weight_mode_supported; > + > + /** Private shaper and scheduler weight mode. > + * When non-zero value indicates that all SP children > + * should have same weight mode and the same > mode > + * applies to private shaper as well. This is only > + * valid if *sched_wfq_weight_mode_supported* is > set. > + */ > + int sched_shaper_private_weight_mode; > + > /** Mask of statistics counter types supported by the > * non-leaf nodes on this level. Every supported > * statistics counter type is supported by at least one See above the comments on TM capabilities. > @@ -735,6 +764,21 @@ struct rte_tm_node_capabilities { > * WFQ weight, so WFQ is reduced to FQ. > */ > uint32_t sched_wfq_weight_max; > + > + /** WFQ weight mode supported. Non-zero value > indicates > + * wfq weight mode is supported and a SP child > + * (even a wfq group) can be configured to use > + * packet-mode or byte-mode for weight > calculations. > + */ > + int sched_wfq_weight_mode_supported; > + > + /** Private shaper and scheduler weight mode. > + * When non-zero value indicates that all SP children > + * should have same weight mode and the same > mode > + * applies to private shaper as well. This is only > + * valid if *sched_wfq_weight_mode_supported* is > set. > + */ > + int sched_shaper_private_weight_mode; > } nonleaf; >=20 > /** Items valid only for leaf nodes. */ See above the comments on the TM capabilities. > @@ -836,10 +880,19 @@ struct rte_tm_wred_params { > * Token bucket > */ > struct rte_tm_token_bucket { > - /** Token bucket rate (bytes per second) */ > + /** Token bucket rate. This is in "bytes per second" by default. > + * For private shaper attached to node that is set in packet mode > + * and tm capability *sched_shaper_private_weight_mode* is set, > + * this is interpreted as "packets per second". > + */ > uint64_t rate; >=20 > - /** Token bucket size (bytes), a.k.a. max burst size */ > + /** Token bucket size, a.k.a. max burst size. > + * This is in "bytes" by default. > + * For private shaper attached to node that is set in packet mode > + * and tm capability *sched_shaper_private_weight_mode* is set, > + * this is interpreted as "packets". > + */ > uint64_t size; > }; >=20 Comments are not correct, as API should allow a combination of both the pac= ket mode and the byte mode (for different nodes, not for the same node), so= both capabilities shaper_rate_packet_mode and shaper_rate_byte_mode can be= set. Hence, the comments should not specify a capability, but the fact tha= t these values can specify either byte or packets, depending on a flag else= where. > @@ -924,7 +977,10 @@ struct rte_tm_node_params { > * indicates that WFQ is to be used for all priorities. > * When non-NULL, it points to a pre-allocated array > of > * *n_sp_priorities* values, with non-zero value for > - * byte-mode and zero for packet-mode. > + * byte-mode and zero for packet-mode. The same > mode is > + * used for private shaper connected to this node if > + * tm capability > *sched_shaper_private_weight_mode* is > + * true. > */ This comment is incorrect, as sched should not be combined with shaper. The= user should select between packet mode and byte mode for the WFQ weight in= dependently of the mode for the shaper rate, although an implementation (dr= iver) should enforce the correct values. > int *wfq_weight_mode; >=20 > -- > 2.8.4 Regards, Cristian