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

[Burakov, Anatoly]

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

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