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

["Richardson, Bruce" <bruce.richardson@intel.com>]

> -----Original Message-----
> From: techboard [mailto:techboard-bounces@dpdk.org] On Behalf Of Ananyev,
> Konstantin
> Sent: Monday, November 12, 2018 11:24 AM
> To: Burakov, Anatoly <anatoly.burakov@intel.com>; Jerin Jacob
> <jerin.jacob@caviumnetworks.com>; dev@dpdk.org
> Cc: techboard@dpdk.org
> Subject: Re: [dpdk-techboard] [dpdk-dev] DPDK techboard minutes of October
> 24
> 
> 
> Hi Anatoly,
> 
> > > Meeting notes for the DPDK technical board meeting held on
> > > 2018-10-24
> > >
> > > Attendees:
> > >          - Bruce Richardson
> > >          - Ferruh Yigit
> > >          - Hemant Agrawal
> > >          - Jerin Jacob
> > >          - Konstantin Ananyev
> > >          - Maxime Coquelin
> > >          - Olivier Matz
> > >          - Stephen Hemminger
> > >          - Thomas Monjalon
> > >
> > > 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!

/Bruce