[dpdk-dev] DPDK techboard minutes of October 24

[dpdk-dev] DPDK techboard minutes of October 24

[Jerin Jacob]

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

1) jonathan.ribas@fraudbuster.mobi approached techboard to
include dpdk replay tool https://github.com/FraudBuster/dpdk-burst-replay
in dpdk.org
- TB to review the content and take the next steps

2) Next techboard meeting
- Konstantin Ananyev will chair it

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

[Burakov, Anatoly]

On 10-Nov-18 9:18 AM, Jerin Jacob wrote:
> 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 :)

-- 
Thanks,
Anatoly

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

[Ananyev, Konstantin]

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

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

[Richardson, Bruce]

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

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

[Ananyev, Konstantin]

> -----Original Message-----
> From: Richardson, Bruce
> Sent: Monday, November 12, 2018 12:22 PM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; 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
> 
> 
> 
> > -----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!

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

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

[Stephen Hemminger]

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

> > -----Original Message-----
> > From: Richardson, Bruce
> > Sent: Monday, November 12, 2018 12:22 PM
> > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; 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
> > 
> > 
> >   
> > > -----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!  
> 
> 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

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

[Thomas Monjalon]

12/11/2018 17:43, Stephen Hemminger:
> On Mon, 12 Nov 2018 12:36:45 +0000
> "Ananyev, Konstantin" <konstantin.ananyev@intel.com> wrote:
> > From: Richardson, Bruce
> > > From: techboard [mailto:techboard-bounces@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.

Re: [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@intel.com> wrote:
>>> From: Richardson, Bruce
>>>> From: techboard [mailto:techboard-bounces@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