on
and complexity which definately slows down the fast uncontended path.
Ideally, an inline version using futex.
Glibc has so much indirection because it supports so many mutex variants
and operating systems like mach and hurd...
The use case RTE lock would address could be
A) Synchronizing d
On Thu, 7 Mar 2024 20:50:26 +0100
Mattias Rönnblom wrote:
> 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 rai
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
> From: Mattias Rönnblom [mailto:hof...@lysator.liu.se]
> Sent: Tuesday, 5 March 2024 21.18
>
> 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.,
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
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 loc
6 matches
Mail list logo
