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

Ananyev, Konstantin konstantin.ananyev at intel.com
Mon Nov 12 13:36:45 CET 2018



> -----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




More information about the dev mailing list