Minutes of DPDK Technical Board Meeting, 2024-04-03
Members Attending: 10/11
- Aaron Conole
- Bruce Richardson
- Hemant Agrawal
- Honnappa Nagarahalli
- Kevin Traynor
- Konstantin Ananyev
- Maxime Coquelin
- Morten Brørup
- Stephen Hemminger
- Thomas Monjalon (Chair)
NOTE: The Technical Board meetings take place every second Wednesday at 3 pm UTC
on https://zoom-lfx.platform.linuxfoundation.org/meeting/96459488340?password=d808f1f6-0a28-4165-929e-5a5bcae7efeb
Meetings are public, and DPDK community members are welcome to attend.
Agenda and minutes can be found at http://core.dpdk.org/techboard/minutes
1/ MSVC
Work to be able to compile DPDK with MSVC is progressing.
Regarding the tooling, UNH CI is testing MSVC in Windows Server 2022 job. There was an ask for GHA job building with MSVC.
Example:
https://github.com/danielzsh/spark/blob/master/.github/workflows/compile.yml
We should not break MSVC compilation for enabled libraries.
When creating a new library, we should require to allow MSVC where it makes sense. Some guidelines could be added in doc/guides/contributing/design.rst
2/ function inlining
There are pros and cons for function inlining.
There should not be inlining in control path functions.
Inlining should be avoided in public headers because of ABI compatibility issue and structures being exported because of inline requirement.
Inlining should be used with care, with benchmarks as a proof of efficiency. Having too much inlining will have a drawback on instruction cache, that's why we should justify any new usage of inline.
Note that the same recommendations apply with the use of prefetch and likely/unlikely.
Quoted 3 lines
Inlining should be avoided in public headers because of ABI compatibility issue
and structures being exported because of inline requirement.
This sounds like a techboard decision, which I don't think it was. Suggested wording:
A disadvantage of inlining in public headers is ABI compatibility issues and structures being exported because of inline requirement.
Perhaps I'm being paranoid, and the phrase "should be" already suffices.
Whichever wording you prefer,
ACK
24/04/2024 19:25, Morten Brørup:
Quoted 7 lines
Quoted 3 lines
Inlining should be avoided in public headers because of ABI compatibility issue
and structures being exported because of inline requirement.This sounds like a techboard decision, which I don't think it was. Suggested wording:
Quoted 7 lines
A disadvantage of inlining in public headers is ABI compatibility issues and structures being exported because of inline requirement.
Perhaps I'm being paranoid, and the phrase "should be" already suffices.
Whichever wording you prefer,
ACK
This is the final report sent to [email protected] :) Yes I think the word "should" reflect what was said during the meeting without any formal vote.