From: Stephen Hemminger <stephen@networkplumber.org>
To: dev@dpdk.org
Subject: Minutes of Technical Board meeting 20-March-2024
Date: Wed, 27 Mar 2024 19:19:24 -0700 [thread overview]
Message-ID: <20240327191924.04bdebb5@hermes.local> (raw)
Members Attending
=================
Aaron Conole
Bruce Richardson
Hemant Agrawal
Jerin Jacob
Kevin Traynor
Konstantin Ananyev
Maxime Coquelin
Morten Brørup
Stephen Hemminger (chair)
Thomas Monjalon
NOTE
====
The technical board meetings are on every second Wednesday at 3 pm UTC.
Meetings are public. DPDK community members are welcome to attend on Zoom:
https://zoom-lfx.platform.linuxfoundation.org/meeting/96459488340?
password=d808f1f6-0a28-4165-929e-5a5bcae7efeb
Agenda: https://annuel.framapad.org/p/r.0c3cc4d1e011214183872a98f6b5c7db
Minutes of previous meetings: http://core.dpdk.org/techboard/minutes
Next meeting will be on Wednesday 3-April-2024 at 3pm UTC, and will be
chaired by Thomas.
Agenda Items
============
1. Lcore variables (Mattias)
This patch series proposes an alternative for per-lcore variables.
Lots of code uses the pattern is per-lcore-data.
This solution is simple but uses lots of padding to handle cache lines;
and it is easy to overlook some cache patterns and get false sharing.
Recent example was hardware will pre-fetch across cache lines.
The per-lcore array model also doesn't handle non-EAL threads well.
One other issue is that accessing thread local storage variables
in another thread works but is undefined according to standards.
The proposal defines yet another allocator for per-thread data.
It is available early in startup other libraries can use use it.
Per-thread allocated storage can safely be used by unregistered threads.
Limitations: it does not completely solve the HW pre-fetch issue,
and it is not a true heap since there is no free or collection function.
Performance is about the same. All implementations have same access pattern.
An added benefit is that there is less chance of false sharing bugs.
Issues:
Valgrind will report leaks. It uses aligned_alloc() and that
function is different on Windows.
Questions:
Should it use hugepages?
startup issue before/after memory setup?
Or hint the OS?
2. 2024 Events update (Nathan)
Planning for North American DPDK summit in Montreal - week of 9 September.
Still pending governing board approval.
Discussions around an Asia-Pacific event in Bangkok Thailand.
This location was suggested as a neutral location (less visa issues).
Early stage discussions, still needs more work by governing board.
There has been large amount of interest in DPDK webinars in APAC.
Are there budget or visa issues with travel for Indian companies?
3. Code Challenge (Ben)
Asked Jim Zemlin about cross-project challenges; he agreed good idea but hard to pull off.
What next steps are needed to make this event work?
Proposal to have DPDK branded merch as part of this.
4. Changes to use markers (Tyler)
Using GCC zero sized arrays, used for alignment and reference and prefetch.
Not available in MSVC. Existing code has inconsistent usage of markers.
Proposed solutions (both maintain ABI):
Option 1: anonymous unions in C11, same API.
Option 2: break API, use existing cacheline prefetch functions.
Existing usage appears to be for prefetch, and hardware rearming.
A hybrid approach is to remove markers for the prefetch usage,
and use anonymous unions for the hardware rearm.
Need a way to prevent introduction of new usage of markers (checkpatch).
reply other threads:[~2024-03-28 2:19 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240327191924.04bdebb5@hermes.local \
--to=stephen@networkplumber.org \
--cc=dev@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).