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.
