[dpdk-dev] [dpdk-techboard] DPDK techboard minutes of October 24

[Thomas Monjalon]

12/11/2018 17:43, Stephen Hemminger:
> On Mon, 12 Nov 2018 12:36:45 +0000
> "Ananyev, Konstantin" <konstantin.ananyev at intel.com> wrote:
> > From: Richardson, Bruce
> > > From: techboard [mailto:techboard-bounces at dpdk.org] On Behalf Of Ananyev,
> > > > Konstantin
> > > >
> > > > Hi Anatoly,
> > > >  
> > > > > > Meeting notes for the DPDK technical board meeting held on
> > > > > > 2018-10-24
[...]
> > > > > > 0) DPDK acceptance policy on un-implemented API
> > > > > > - New APIs without implementation is not accepted.
> > > > > > - In order to accept a new API, At minimum
> > > > > > a) Need to provide an unit test case or example application
> > > > > > b) If the API is about HW abstraction, at least one driver should be
> > > > > > implemented. Preferably two.
> > > > > > c) If there are strong objections on ML about the need for more than
> > > > > > one driver for a specific API then the technical board can make a
> > > > > > decision.
> > > > > > - Konstantin volunteered to send existing un-implemented API to the
> > > > > > mailing list.
> > > > > > - The existing un-implemented APIs will be deprecated in v19.05.
> > > > > > - Deprecated un-implemented API will be removed in v19.08
> > > > > >  
> > > > >
> > > > > Does this also apply to unimplemented parts of the existing API? For
> > > > > example, malloc API has long had a "name" parameter which goes
> > > > > unimplemented through entire lifetime of DPDK project. It would be
> > > > > good to drop this thing entirely as it's clear it's not going to be
> > > > > implemented any time soon :)
> > > > >  
> > > >
> > > > Sounds like a good idea to me.
> > > > Konstantin  
> > > 
> > > While a good idea in theory, I'm not sure the cost-benefit pays off for this one. Given the fact that the extra parameter is rather harmless,
> > > the benefit seems minimal compared to the effort which would be involved for everyone to have to change every rte_malloc call in every
> > > app!  
> > 
> > I am agree about massive amount of changes, though I thought Anatoly sort of volunteering for it :)
> > About benefit - it would save us spilling/restoring one register for each rte_malloc() call.
> > Probably not that important, as  rte_malloc() usually is used from data-path, but still. 
> > Plus it doesn't look good to have a function with parameter  that would never be used.
> > Konstantin
> > 
> > 
> 
> I agree, we should do these kind of cleanups, but only on ABI breaking releases.
> Too late now for 18.11 and next one is probably 19.11

We can discuss which release can break ABI.
I think 19.05 is a good candidate.