From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 0F0CD108A for ; Tue, 7 Mar 2017 20:30:01 +0100 (CET) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Mar 2017 11:30:00 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,258,1486454400"; d="scan'208";a="72747670" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by orsmga005.jf.intel.com with ESMTP; 07 Mar 2017 11:29:59 -0800 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.173]) by IRSMSX102.ger.corp.intel.com ([169.254.2.230]) with mapi id 14.03.0248.002; Tue, 7 Mar 2017 19:29:58 +0000 From: "Dumitrescu, Cristian" To: Thomas Monjalon CC: "dev@dpdk.org" , "jerin.jacob@caviumnetworks.com" , "balasubramanian.manoharan@cavium.com" , "hemant.agrawal@nxp.com" , "shreyansh.jain@nxp.com" , "Wiles, Keith" , "Richardson, Bruce" , "O'Driscoll, Tim" Thread-Topic: [PATCH v3 2/2] ethdev: add hierarchical scheduler API Thread-Index: AQHSlmXkX5aIvTYL1U6GZzZccGSDv6GIAuLQgAA63gCAAYJR4A== Date: Tue, 7 Mar 2017 19:29:57 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D891265275BDC0@IRSMSX108.ger.corp.intel.com> References: <1488589820-206947-1-git-send-email-cristian.dumitrescu@intel.com> <6158991.OypYtkqGNY@xps13> <3EB4FA525960D640B5BDFFD6A3D891265275A053@IRSMSX108.ger.corp.intel.com> <3752751.fl3uBnnZGo@xps13> In-Reply-To: <3752751.fl3uBnnZGo@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYWM2MTkwNjUtMjM0NC00OGUzLWFjOWItNzA3YjJjMTBjZDQzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjIuMTEuMCIsIlRydXN0ZWRMYWJlbEhhc2giOiJnRktEK3F4Q2F0ekNqSXBwTkhhSkpmVzJXZExrNjlnMzRNZHJUb2FkSkN3PSJ9 x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v3 2/2] ethdev: add hierarchical scheduler API 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: , X-List-Received-Date: Tue, 07 Mar 2017 19:30:02 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Monday, March 6, 2017 8:07 PM > To: Dumitrescu, Cristian > Cc: dev@dpdk.org; jerin.jacob@caviumnetworks.com; > balasubramanian.manoharan@cavium.com; hemant.agrawal@nxp.com; > shreyansh.jain@nxp.com; Wiles, Keith ; Richardson, > Bruce > Subject: Re: [PATCH v3 2/2] ethdev: add hierarchical scheduler API >=20 > 2017-03-06 16:59, Dumitrescu, Cristian: > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > > 2017-03-04 01:10, Cristian Dumitrescu: > > > > This patch introduces the generic ethdev API for the traffic manage= r > > > > capability, which includes: hierarchical scheduling, traffic shapin= g, > > > > congestion management, packet marking. > > > > > > We already have some API for QoS. Why integrating them in ethdev? > > > ethdev is an interface for networking drivers. > > > I think the QoS has nothing to do with drivers. > > > If there are some operations to offload in drivers, please identify t= hem > > > and let's add the operations to ethdev. > > > > > > > The reason to add to ethdev is because QoS traffic > management/hierarchical scheduling is just another TX offload for Etherne= t > devices. This TX offload is present in NICs, NPUs and SoCs from Broadcom, > Cavium, Intel, Mellanox, Netronome, NXP, others. > > > > The API we currently have in DPDK (librte_sched) is great, but it refer= s to > an implementation for a fixed set of features for a BRAS-like hierarchy. = The > current abstraction layer proposal is intended to support pretty much any > hierarchy and traffic management features such as hierarchical scheduling= , > traffic shaping, congestion management, marking under the same API. It > targets pretty much any implementation, either HW, SW or hybrid; it does > support the existing librte_sched library feature set, but it is not limi= ted to it. >=20 > OK I better understand now. > You should add this level of explanation in your patch. >=20 > However I am reluctant to add an API if there is no user. > I think we should wait to have at least one existing driver implementing > this API before integrating it. > It was the approach of eventdev which has a dedicated next- tree. The next-tree solution could work, but IMO is not the best for this case, a= s this is purely driver development. This is just a TX offload feature that= is well understood, as opposed to a new library with a huge design effort = required like eventdev. I think we are reasonably close to get agreement on the API from Cavium, In= tel and NXP. When this is done, how about including it in DPDK with the exp= erimental tag attached to it until several drivers implement it? >>From Intel side, there are solid plans to implement it for ixgbe and i40e d= rivers in next DPDK releases, I am CC-ing Tim to confirm this. On Cavium an= d NXP side, Jerin and Hemant can comment on the plans to implement this API= .