DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev]  DPDK techboard minutes of October 24
@ 2018-11-10  9:18 Jerin Jacob
  2018-11-12  9:34 ` Burakov, Anatoly
  0 siblings, 1 reply; 8+ messages in thread
From: Jerin Jacob @ 2018-11-10  9:18 UTC (permalink / raw)
  To: dev; +Cc: techboard

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [dpdk-dev] DPDK techboard minutes of October 24
  2018-11-10  9:18 [dpdk-dev] DPDK techboard minutes of October 24 Jerin Jacob
@ 2018-11-12  9:34 ` Burakov, Anatoly
  2018-11-12 11:24   ` [dpdk-dev] [dpdk-techboard] " Ananyev, Konstantin
  0 siblings, 1 reply; 8+ messages in thread
From: Burakov, Anatoly @ 2018-11-12  9:34 UTC (permalink / raw)
  To: Jerin Jacob, dev; +Cc: techboard

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [dpdk-dev] [dpdk-techboard] DPDK techboard minutes of October 24
  2018-11-12  9:34 ` Burakov, Anatoly
@ 2018-11-12 11:24   ` Ananyev, Konstantin
  2018-11-12 12:21     ` Richardson, Bruce
  0 siblings, 1 reply; 8+ messages in thread
From: Ananyev, Konstantin @ 2018-11-12 11:24 UTC (permalink / raw)
  To: Burakov, Anatoly, Jerin Jacob, dev; +Cc: techboard


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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [dpdk-dev] [dpdk-techboard] DPDK techboard minutes of October 24
  2018-11-12 11:24   ` [dpdk-dev] [dpdk-techboard] " Ananyev, Konstantin
@ 2018-11-12 12:21     ` Richardson, Bruce
  2018-11-12 12:36       ` Ananyev, Konstantin
  0 siblings, 1 reply; 8+ messages in thread
From: Richardson, Bruce @ 2018-11-12 12:21 UTC (permalink / raw)
  To: Ananyev, Konstantin, Burakov, Anatoly, Jerin Jacob, dev; +Cc: techboard



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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [dpdk-dev] [dpdk-techboard] DPDK techboard minutes of October 24
  2018-11-12 12:21     ` Richardson, Bruce
@ 2018-11-12 12:36       ` Ananyev, Konstantin
  2018-11-12 16:43         ` Stephen Hemminger
  0 siblings, 1 reply; 8+ messages in thread
From: Ananyev, Konstantin @ 2018-11-12 12:36 UTC (permalink / raw)
  To: Richardson, Bruce, Burakov, Anatoly, Jerin Jacob, dev; +Cc: techboard



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



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [dpdk-dev] [dpdk-techboard] DPDK techboard minutes of October 24
  2018-11-12 12:36       ` Ananyev, Konstantin
@ 2018-11-12 16:43         ` Stephen Hemminger
  2018-11-12 16:55           ` Thomas Monjalon
  0 siblings, 1 reply; 8+ messages in thread
From: Stephen Hemminger @ 2018-11-12 16:43 UTC (permalink / raw)
  To: Ananyev, Konstantin
  Cc: Richardson, Bruce, Burakov, Anatoly, Jerin Jacob, dev, techboard

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [dpdk-dev] [dpdk-techboard] DPDK techboard minutes of October 24
  2018-11-12 16:43         ` Stephen Hemminger
@ 2018-11-12 16:55           ` Thomas Monjalon
  2018-11-13  9:33             ` Burakov, Anatoly
  0 siblings, 1 reply; 8+ messages in thread
From: Thomas Monjalon @ 2018-11-12 16:55 UTC (permalink / raw)
  To: Stephen Hemminger
  Cc: techboard, Ananyev, Konstantin, Richardson, Bruce, Burakov,
	Anatoly, Jerin Jacob, dev

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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [dpdk-dev] [dpdk-techboard] DPDK techboard minutes of October 24
  2018-11-12 16:55           ` Thomas Monjalon
@ 2018-11-13  9:33             ` Burakov, Anatoly
  0 siblings, 0 replies; 8+ messages in thread
From: Burakov, Anatoly @ 2018-11-13  9:33 UTC (permalink / raw)
  To: Thomas Monjalon, Stephen Hemminger
  Cc: techboard, Ananyev, Konstantin, Richardson, Bruce, Jerin Jacob, dev

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2018-11-13  9:33 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-10  9:18 [dpdk-dev] DPDK techboard minutes of October 24 Jerin Jacob
2018-11-12  9:34 ` Burakov, Anatoly
2018-11-12 11:24   ` [dpdk-dev] [dpdk-techboard] " Ananyev, Konstantin
2018-11-12 12:21     ` Richardson, Bruce
2018-11-12 12:36       ` Ananyev, Konstantin
2018-11-12 16:43         ` Stephen Hemminger
2018-11-12 16:55           ` Thomas Monjalon
2018-11-13  9:33             ` Burakov, Anatoly

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git