On 2024-03-05 22:02, Tyler Retzlaff wrote:
On Tue, Mar 05, 2024 at 09:18:20PM +0100, Mattias Rönnblom wrote:
Shouldn't we have a DPDK-native mutex API, rather than using direct
POSIX mutex lock calls?
David raised this a while back and the consensus is yes. I admit it's
been on my radar for a long time for the obvious reasons you list below
but with other work hasn't been a priority (yet).
There are two reasons for this, as I see it
1) more cleanly support non-POSIX operating system (i.e., Microsoft
Windows).
2) to discourage mechanical use of spinlocks in places where a
regular mutex lock is more appropriate.
I think (and hope) DPDK developers will tend to pick DPDK-native
rather than other APIs as their first choice.
I spent some time evaluating C11 mutex but it really didn't strike me as
being fit for purpose so I think DPDK-native is probably the only way to
go. If behind the scenes particular locks relied on something standard
for Windows perhaps it could be hidden as an implementation detail.
What was it you were missing?
I'm not familiar with C11 mtx_*()
For locks, they go for spinlocks, even in control (non-fast
path/non-packet processing) code paths (e.g., calls made by the
typical non-EAL thread).
Using spinlocks to synchronize threads that may be preempted aren't
great idea.
If you're thinking of looking into this i'd be happy to see it solved.
I have no immediate plans, but this might be something I'll do in the
future.
ty
