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

Stephen Hemminger stephen at networkplumber.org
Mon Nov 12 17:43:53 CET 2018


On Mon, 12 Nov 2018 12:36:45 +0000
"Ananyev, Konstantin" <konstantin.ananyev at intel.com> wrote:

> > -----Original Message-----
> > From: Richardson, Bruce
> > Sent: Monday, November 12, 2018 12:22 PM
> > To: Ananyev, Konstantin <konstantin.ananyev at intel.com>; Burakov, Anatoly <anatoly.burakov at intel.com>; Jerin Jacob
> > <jerin.jacob at caviumnetworks.com>; dev at dpdk.org
> > Cc: techboard at dpdk.org
> > Subject: RE: [dpdk-techboard] [dpdk-dev] DPDK techboard minutes of October 24
> > 
> > 
> >   
> > > -----Original Message-----
> > > From: techboard [mailto:techboard-bounces at dpdk.org] On Behalf Of Ananyev,
> > > Konstantin
> > > Sent: Monday, November 12, 2018 11:24 AM
> > > To: Burakov, Anatoly <anatoly.burakov at intel.com>; Jerin Jacob
> > > <jerin.jacob at caviumnetworks.com>; dev at dpdk.org
> > > Cc: techboard at 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!  
> 
> 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


More information about the dev mailing list