> -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] > Sent: Thursday, March 16, 2017 5:30 PM > To: Dumitrescu, Cristian <cristian.dumitre...@intel.com> > Cc: O'Driscoll, Tim <tim.odrisc...@intel.com>; dev@dpdk.org; > jerin.ja...@caviumnetworks.com; > balasubramanian.manoha...@cavium.com; hemant.agra...@nxp.com; > shreyansh.j...@nxp.com; Wiles, Keith <keith.wi...@intel.com>; Richardson, > Bruce <bruce.richard...@intel.com> > Subject: Re: [PATCH v3 2/2] ethdev: add hierarchical scheduler API > > 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? > > 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?
