DPDK techboard minutes of October 24

DISCUSSION Jerin Jacob 6 participants 8 messages Nov 10, 2018 – Nov 13, 2018

Share & tools

Jerin Jacob

author

2018-11-10 09:18 UTC #0 lore raw

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) [email protected] 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

Burakov, Anatoly

2018-11-12 09:34 UTC #1 lore raw

Quoted 14 lines · 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

Quoted 14 lines

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

Signature · 2 lines

Thanks,
Anatoly

Ananyev, Konstantin

2018-11-12 11:24 UTC #2 lore raw

Hi Anatoly,

Quoted 29 lines

Quoted 14 lines
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
Quoted 14 lines
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

Quoted 6 lines

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

Richardson, Bruce

2018-11-12 12:21 UTC #3 lore raw

Quoted 51 lines

-----Original Message-----
From: techboard [mailto:[email protected]] On Behalf Of Ananyev, Konstantin
Sent: Monday, November 12, 2018 11:24 AM
To: Burakov, Anatoly <[email protected]>; Jerin Jacob <[email protected]>; [email protected]
Cc: [email protected]
Subject: Re: [dpdk-techboard] [dpdk-dev] DPDK techboard minutes of October 24
Hi Anatoly,
Quoted 29 lines
Quoted 14 lines
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
Quoted 14 lines
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
Quoted 6 lines
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 :)

Quoted 2 lines

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

Ananyev, Konstantin

2018-11-12 12:36 UTC #4 lore raw

Quoted 61 lines

-----Original Message-----
From: Richardson, Bruce
Sent: Monday, November 12, 2018 12:22 PM
To: Ananyev, Konstantin <[email protected]>; Burakov, Anatoly <[email protected]>; Jerin Jacob <[email protected]>; [email protected]
Cc: [email protected]
Subject: RE: [dpdk-techboard] [dpdk-dev] DPDK techboard minutes of October 24
Quoted 49 lines
-----Original Message-----
From: techboard [mailto:[email protected]] On Behalf Of Ananyev, Konstantin
Sent: Monday, November 12, 2018 11:24 AM
To: Burakov, Anatoly <[email protected]>; Jerin Jacob <[email protected]>; [email protected]
Cc: [email protected]
Subject: Re: [dpdk-techboard] [dpdk-dev] DPDK techboard minutes of October 24
Hi Anatoly,
Quoted 35 lines
Quoted 14 lines
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
Quoted 14 lines
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 :)

Quoted 6 lines

Quoted 2 lines
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

Stephen Hemminger

2018-11-12 16:44 UTC #5 lore raw

Quoted 66 lines · Konstantin

Quoted 59 lines
-----Original Message-----
From: Richardson, Bruce
Sent: Monday, November 12, 2018 12:22 PM
To: Ananyev, Konstantin <[email protected]>; Burakov, Anatoly <[email protected]>; Jerin Jacob <[email protected]>; [email protected]
Cc: [email protected]
Subject: RE: [dpdk-techboard] [dpdk-dev] DPDK techboard minutes of October 24
Quoted 49 lines
-----Original Message-----
From: techboard [mailto:[email protected]] On Behalf Of Ananyev, Konstantin
Sent: Monday, November 12, 2018 11:24 AM
To: Burakov, Anatoly <[email protected]>; Jerin Jacob <[email protected]>; [email protected]
Cc: [email protected]
Subject: Re: [dpdk-techboard] [dpdk-dev] DPDK techboard minutes of October 24
Hi Anatoly,
Quoted 35 lines
Quoted 14 lines
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
Quoted 14 lines
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 :)
Quoted 6 lines
Quoted 2 lines
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!

Quoted 7 lines

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

Thomas Monjalon

2018-11-12 16:55 UTC #6 lore raw

12/11/2018 17:43, Stephen Hemminger:

Quoted 10 lines

Quoted 8 lines · Konstantin
From: Richardson, Bruce
Quoted 7 lines
From: techboard [mailto:[email protected]] On Behalf Of Ananyev,
Quoted 6 lines
Konstantin
Hi Anatoly,
Quoted 2 lines
Quoted 2 lines
Meeting notes for the DPDK technical board meeting held on 2018-10-24

[...]

Quoted 37 lines

Quoted 29 lines
Quoted 22 lines
Quoted 22 lines
Quoted 21 lines
Quoted 5 lines
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
Quoted 9 lines
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 :)
Quoted 6 lines
Quoted 2 lines
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!
Quoted 7 lines
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

Quoted 2 lines

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.

Burakov, Anatoly

2018-11-13 09:33 UTC #7 lore raw

Quoted 49 lines · Thomas Monjalon

12/11/2018 17:43, Stephen Hemminger:
Quoted 10 lines
Quoted 8 lines · Konstantin
From: Richardson, Bruce
Quoted 7 lines
From: techboard [mailto:[email protected]] On Behalf Of Ananyev,
Quoted 6 lines
Konstantin
Hi Anatoly,
Quoted 2 lines
Quoted 2 lines
Meeting notes for the DPDK technical board meeting held on 2018-10-24
[...]
Quoted 37 lines
Quoted 36 lines
Quoted 22 lines
Quoted 22 lines
Quoted 21 lines
Quoted 5 lines
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
Quoted 9 lines
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 :)
Quoted 6 lines
Quoted 2 lines
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

Quoted 6 lines

Quoted 2 lines
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.

Signature · 2 lines

Thanks,
Anatoly