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. > > 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. ty
