Shouldn't we have a DPDK-native mutex API, rather than using direct
POSIX mutex lock calls?
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.
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.