RTE lock

Mattias Rönnblom hofors at lysator.liu.se
Thu Mar 7 20:50:26 CET 2024


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


More information about the dev mailing list