Re: [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: Thursday, March 16, 2017 6:11 PM
> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Ananyev,
> Konstantin <konstantin.ananyev@intel.com>
> Cc: O'Driscoll, Tim <tim.odriscoll@intel.com>; dev@dpdk.org;
> jerin.jacob@caviumnetworks.com;
> balasubramanian.manoharan@cavium.com; hemant.agrawal@nxp.com;
> shreyansh.jain@nxp.com; Wiles, Keith <keith.wiles@intel.com>; Richardson,
> Bruce <bruce.richardson@intel.com>; techboard@dpdk.org
> Subject: Re: [PATCH v3 2/2] ethdev: add hierarchical scheduler API
> 
> 2017-03-16 17:40, Dumitrescu, Cristian:
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > > 2017-03-16 16:23, Dumitrescu, Cristian:
> > > > ... <snip>
> > > >
> > > > > > 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)?
> > > > >
> > > > > I think starting a branch in a dedicated "next" repo is a better
> approach.
> > > > > rte_flow and eventdev were (and will be) integrated only when at
> least
> > > one
> > > > > hardware device is supported.
> > > > > I suggest to follow the same workflow.
> > > > >
> > > >
> > > > Thomas, if this is the only path forward you are willing to support, then
> let's
> > > go this way, but let's make sure we are all on the same page with the
> terms
> > > and conditions that apply.
> > > >
> > > > Do you agree now to merge this next-tree to DPDK once this API is
> > > implemented for at least one PMD? We would like to avoid getting any
> last
> > > minute objections from you or anybody else on the fundamentals; if you
> > > have any, please let's discuss them now.
> > >
> > > At least one "hardware" PMD, yes. It would prove the API can work for
> real.
> > > About accepting it definitely in a given release, it will be checked
> > > with the technical board on Monday.
> > >
> >
> > OK, great, thank you. Is the agenda of the technical board meetings
> published in advance somewhere?
> 
> For the previous meeting, it was published:
> 	https://bimestriel.framapad.org/p/r.a5199d22813a5ac79d1d365b9ce
> cb905
> For the next one, please Konstantin, could you publish the agenda on a pad?
> 
> > > > How do we manage the API freeze on the next-tree? Once the API is
> > > agreed, we would like to freeze it so the driver development can
> proceed;
> > > we can then do some reasonably small changes to the API based on the
> > > learnings we get during driver development. We would like to welcome
> any
> > > parties interested in contributing to join Cavium, Intel and NXP in this
> effort,
> > > but we would like to avoid any last minute major API change requests.
> > >
> > > You are taking it the wrong way. Your main concern is to not be disturbed
> > > with change requests. It should be the contrary: you have a chance to
> > > work with other vendors to test and improve the API.
> > > You should embrace this chance and delay the API freeze as much as
> > > possible.
> >
> > Not really. We definitely welcome change requests done in a timely
> manner. My concern is about last minute change requests, such as major API
> change requests just a few days before the release when driver
> development is complete. Is there a policy in place to prevent against such
> events for next-tree type of development?
> 
> No there is no such policy on a next- tree.
> It is free to the maintainer of the tree I guess.

Thanks, Thomas. Can you please create a next-tree for QoS Traffic Management with the following details:
	Maintainer: Cristian
	Committers: Hemant, Jerin, Cristian