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