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 A47EEA2EFC for ; Mon, 14 Oct 2019 16:23:47 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8C6341C11C; Mon, 14 Oct 2019 16:23:46 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id E23731BF45 for ; Mon, 14 Oct 2019 16:23:44 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Oct 2019 07:23:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,295,1566889200"; d="scan'208";a="225092442" Received: from irsmsx151.ger.corp.intel.com ([163.33.192.59]) by fmsmga002.fm.intel.com with ESMTP; 14 Oct 2019 07:23:43 -0700 Received: from irsmsx112.ger.corp.intel.com (10.108.20.5) by IRSMSX151.ger.corp.intel.com (163.33.192.59) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 14 Oct 2019 15:23:42 +0100 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.131]) by irsmsx112.ger.corp.intel.com ([169.254.1.60]) with mapi id 14.03.0439.000; Mon, 14 Oct 2019 15:23:42 +0100 From: "Dumitrescu, Cristian" To: "Singh, Jasvinder" , "dev@dpdk.org" Thread-Topic: [PATCH v4 00/17] sched: subport level configuration of pipe nodes Thread-Index: AQHVgn/wwjHQrZDdH0Wq1LezxCn14adaL+VQ Date: Mon, 14 Oct 2019 14:23:42 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D891268E942CA0@IRSMSX108.ger.corp.intel.com> References: <20190926085232.47667-1-jasvinder.singh@intel.com> <20191014120951.152654-1-jasvinder.singh@intel.com> In-Reply-To: <20191014120951.152654-1-jasvinder.singh@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMGEwZGUxODQtNmRmNi00NDI2LWE3MmMtZjE0MmIzYjhlZDZjIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiQXdBTkVzOG8wajZuSDE2ZGtoWkx1bFhEZGtoNzA5OFNZQlRINDhcL09OQWxJZzB0c0pMSDJsNWZWTXlPZG1uMCsifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v4 00/17] sched: subport level configuration of pipe nodes 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" > -----Original Message----- > From: Singh, Jasvinder > Sent: Monday, October 14, 2019 1:10 PM > To: dev@dpdk.org > Cc: Dumitrescu, Cristian > Subject: [PATCH v4 00/17] sched: subport level configuration of pipe node= s >=20 > This patchset refactors the dpdk qos sched library to allow subport > level configuration flexibility of the pipe nodes. >=20 > Currently, all parameters for the pipe nodes (subscribers) > configuration are part of the port level structure which forces > all groups of subscribers (pipes) in different subports to > have similar configurations in terms of their number, queue sizes, > traffic-classes, etc. >=20 > The new implementation moves pipe nodes configuration parameters > from port level to subport level structure. This allows different > subports of the same port to have different configuration for the > pipe nodes, for examples- number of pipes, queue sizes, pipe > profiles, etc. >=20 > In order to keep the implementation complexity under control, all > pipes within the same subport share the same configuration for queue > sizes. >=20 > v4: > - remove deprecation note > - rebase on current dpdk head > - add 64-bit values support >=20 Hi Jasvinder, I think the 64-bit counter support is a distinct unrelated feature, and I s= uggest we send a separate patchset for it. It also saves us re-reviewing th= e large patchset that was already reviewed? Regards, Cristian