Re: [dpdk-dev] [PATCH v6 3/4] eal: use wait event scheme for mcslock
From: Mattias Rönnblom <hidden>
Date: 2021-10-27 11:16:29
On 2021-10-27 10:10, Feifei Wang wrote:
quoted hunk ↗ jump to hunk
Instead of polling for mcslock to be updated, use wait event scheme for this case. Signed-off-by: Feifei Wang <redacted> Reviewed-by: Ruifeng Wang <redacted> --- lib/eal/include/generic/rte_mcslock.h | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)diff --git a/lib/eal/include/generic/rte_mcslock.h b/lib/eal/include/generic/rte_mcslock.h index 34f33c64a5..806a2b2c7e 100644 --- a/lib/eal/include/generic/rte_mcslock.h +++ b/lib/eal/include/generic/rte_mcslock.h@@ -116,8 +116,13 @@ rte_mcslock_unlock(rte_mcslock_t **msl, rte_mcslock_t *me) /* More nodes added to the queue by other CPUs. * Wait until the next pointer is set. */ - while (__atomic_load_n(&me->next, __ATOMIC_RELAXED) == NULL) - rte_pause(); +#ifdef RTE_ARCH_32 + rte_wait_event((uint32_t *)&me->next, UINT32_MAX, ==, 0, + __ATOMIC_RELAXED); +#else + rte_wait_event((uint64_t *)&me->next, UINT64_MAX, ==, 0, + __ATOMIC_RELAXED); +#endif } /* Pass lock to next waiter. */
You could do something like rte_wait_event((uintptr_t *)&me->next, UINTPTR_MAX, ==, 0, __ATOMIC_RELAXED); and avoid the #ifdef.