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.

Reply via email to