From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 510AA5597 for ; Wed, 8 Mar 2017 10:51:55 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Mar 2017 01:51:54 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,262,1486454400"; d="scan'208";a="941934462" Received: from irsmsx154.ger.corp.intel.com ([163.33.192.96]) by orsmga003.jf.intel.com with ESMTP; 08 Mar 2017 01:51:52 -0800 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.173]) by IRSMSX154.ger.corp.intel.com ([169.254.12.40]) with mapi id 14.03.0248.002; Wed, 8 Mar 2017 09:51:51 +0000 From: "O'Driscoll, Tim" To: "Dumitrescu, Cristian" , 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" Thread-Topic: [PATCH v3 2/2] ethdev: add hierarchical scheduler API Thread-Index: AQHSl3k1aEF4OaUahESrV5wjy/llAKGKtAuA Date: Wed, 8 Mar 2017 09:51:51 +0000 Message-ID: <26FA93C7ED1EAA44AB77D62FBE1D27BA7231952B@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> <3EB4FA525960D640B5BDFFD6A3D891265275BDC0@IRSMSX108.ger.corp.intel.com> In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D891265275BDC0@IRSMSX108.ger.corp.intel.com> Accept-Language: en-IE, 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.181] 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: Wed, 08 Mar 2017 09:51:55 -0000 > From: Dumitrescu, Cristian >=20 > > -----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 > > > > 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 > manager > > > > > capability, which includes: hierarchical scheduling, traffic > shaping, > > > > > 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 them > > > > 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 > Ethernet > > 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 > refers 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 > limited to it. > > > > OK I better understand now. > > You should add this level of explanation in your patch. > > > > 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. >=20 > The next-tree solution could work, but IMO is not the best for this > case, as 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. >=20 > I think we are reasonably close to get agreement on the API from Cavium, > Intel and NXP. When this is done, how about including it in DPDK with > the experimental tag attached to it until several drivers implement it? >=20 > From Intel side, there are solid plans to implement it for ixgbe and > i40e drivers in next DPDK releases, I am CC-ing Tim to confirm this. That's correct. We plan to add support for this in the ixgbe and i40e drive= rs in 17.08. > On > Cavium and NXP side, Jerin and Hemant can comment on the plans to > implement this API.