> From: Dumitrescu, Cristian > > > -----Original Message----- > > From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] > > Sent: Monday, March 6, 2017 8:07 PM > > To: Dumitrescu, Cristian <cristian.dumitre...@intel.com> > > Cc: dev@dpdk.org; jerin.ja...@caviumnetworks.com; > > balasubramanian.manoha...@cavium.com; hemant.agra...@nxp.com; > > shreyansh.j...@nxp.com; Wiles, Keith <keith.wi...@intel.com>; > Richardson, > > Bruce <bruce.richard...@intel.com> > > Subject: Re: [PATCH v3 2/2] ethdev: add hierarchical scheduler API > > > > 2017-03-06 16:59, Dumitrescu, Cristian: > > > From: Thomas Monjalon [mailto:thomas.monja...@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. > > 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. > > 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? > > 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 drivers in 17.08. > On > Cavium and NXP side, Jerin and Hemant can comment on the plans to > implement this API.
