Minutes of DPDK Technical Board Meeting, 2024-04-03

Minutes of DPDK Technical Board Meeting, 2024-04-03

[Thomas Monjalon]

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.

RE: Minutes of DPDK Technical Board Meeting, 2024-04-03

[Morten Brørup]

> 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

Re: Minutes of DPDK Technical Board Meeting, 2024-04-03

[Thomas Monjalon]

24/04/2024 19:25, Morten Brørup:
> > 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

This is the final report sent to dev@dpdk.org :)
Yes I think the word "should" reflect what was said
during the meeting without any formal vote.