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

[O'Driscoll, Tim]

> From: Dumitrescu, Cristian
> 
> > -----Original Message-----
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > Sent: Monday, March 6, 2017 8:07 PM
> > To: Dumitrescu, Cristian <cristian.dumitrescu at intel.com>
> > Cc: dev at dpdk.org; jerin.jacob at caviumnetworks.com;
> > balasubramanian.manoharan at cavium.com; hemant.agrawal at nxp.com;
> > shreyansh.jain at nxp.com; Wiles, Keith <keith.wiles at intel.com>;
> Richardson,
> > Bruce <bruce.richardson at 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.monjalon at 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.