On 12-Nov-18 4:55 PM, Thomas Monjalon wrote:
12/11/2018 17:43, Stephen Hemminger:
On Mon, 12 Nov 2018 12:36:45 +0000
"Ananyev, Konstantin" <konstantin.anan...@intel.com> wrote:
From: Richardson, Bruce
From: techboard [mailto:techboard-boun...@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.
There's not much *actual* work involved in the rte_malloc change -
mostly search-and-replace. Given the head-start, i can go on with this
in the background so that it doesn't take away from my day-to-day
activities, and get it ready for 19.05 in time.
--
Thanks,
Anatoly
