From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 09583FA5C for ; Mon, 6 Mar 2017 17:59:10 +0100 (CET) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga105.jf.intel.com with ESMTP; 06 Mar 2017 08:59:09 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,254,1484035200"; d="scan'208";a="232873979" Received: from irsmsx107.ger.corp.intel.com ([163.33.3.99]) by fmsmga004.fm.intel.com with ESMTP; 06 Mar 2017 08:59:08 -0800 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.173]) by IRSMSX107.ger.corp.intel.com ([169.254.10.3]) with mapi id 14.03.0248.002; Mon, 6 Mar 2017 16:59:07 +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" Thread-Topic: [PATCH v3 2/2] ethdev: add hierarchical scheduler API Thread-Index: AQHSlmXkX5aIvTYL1U6GZzZccGSDv6GIAuLQ Date: Mon, 6 Mar 2017 16:59:07 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D891265275A053@IRSMSX108.ger.corp.intel.com> References: <1488589820-206947-1-git-send-email-cristian.dumitrescu@intel.com> <1488589820-206947-3-git-send-email-cristian.dumitrescu@intel.com> <6158991.OypYtkqGNY@xps13> In-Reply-To: <6158991.OypYtkqGNY@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZDY0ZDgwNWUtMTQ3Zi00YThiLTk5NTctZGU5OTk0YTU2NWVhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjIuMTEuMCIsIlRydXN0ZWRMYWJlbEhhc2giOiI2bDJcL0xFMUsyVnpNQ1I3TDVrR2R6cTMxR1ZTRU9KSWdjRGIzRXJBZ1BrUT0ifQ== 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: Mon, 06 Mar 2017 16:59:11 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Monday, March 6, 2017 10:39 AM > To: Dumitrescu, Cristian > Cc: dev@dpdk.org; jerin.jacob@caviumnetworks.com; > balasubramanian.manoharan@cavium.com; hemant.agrawal@nxp.com; > shreyansh.jain@nxp.com > Subject: Re: [PATCH v3 2/2] ethdev: add hierarchical scheduler API >=20 > 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. >=20 > 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. >=20 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. T= he current abstraction layer proposal is intended to support pretty much an= y hierarchy and traffic management features such as hierarchical scheduling= , traffic shaping, congestion management, marking under the same API. It ta= rgets pretty much any implementation, either HW, SW or hybrid; it does supp= ort the existing librte_sched library feature set, but it is not limited to= it. > > Main features: > > - Exposed as ethdev plugin capability (similar to rte_flow approach) >=20 > I do not know what you call an ethdev plugin. > rte_flow is a part of the driver interface. We extend the ethdev feature set using a feature-specific name space and se= parate files (module/plugin-like) as opposed to simply adding new functions= in structure eth_dev_ops in file rte_ethdev.h (IMO monolithic approach), s= imilar to rte_flow, which is already part of DPDK.