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

Dumitrescu, Cristian cristian.dumitrescu at intel.com
Fri Mar 10 19:37:30 CET 2017

> -----Original Message-----
> From: O'Driscoll, Tim
> Sent: Wednesday, March 8, 2017 9:52 AM
> To: Dumitrescu, Cristian <cristian.dumitrescu at intel.com>; Thomas Monjalon
> <thomas.monjalon at 6wind.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
> > From: Dumitrescu, Cristian
> >


> > > 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.

Thomas, given Tim's confirmation of Intel's plans to implement this API for the ixgbe and i40e drivers in DPDK release 17.8, are you in favour of including this API in 17.5 with experimental tag (subject to full API agreement being reached)?

IMO this approach has the advantage of showing that API agreement has been reached and driver development is in progress. Having it in DPDK is also a better way to advertise this API to the developers that would otherwise be unaware about this effort.

> > On
> > Cavium and NXP side, Jerin and Hemant can comment on the plans to
> > implement this API.

More information about the dev mailing list