RTE lock

[Mattias Rönnblom]

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.