Re: [dpdk-dev] [PATCH v3 2/2] ethdev: add hierarchical scheduler API

["Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>]

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Monday, March 6, 2017 10:39 AM
> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> 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
> 
> 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.

> > Main features:
> > - Exposed as ethdev plugin capability (similar to rte_flow approach)
> 
> 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 separate files (module/plugin-like) as opposed to simply adding new functions in structure eth_dev_ops in file rte_ethdev.h (IMO monolithic approach), similar to rte_flow, which is already part of DPDK.