On Wed, 17 Jun 2026 at 10:10, Maxime Peim <[email protected]> wrote: > > Threads registered via rte_thread_register() are assigned a valid > lcore_id by eal_lcore_non_eal_allocate(), but their core_index in > lcore_config is left at -1. This value was set during rte_eal_cpu_init() > for lcores with ROLE_OFF (undetected CPUs) and is never updated when the > lcore is later allocated to a non-EAL thread. > > As a result, rte_lcore_index() returns -1 for registered non-EAL > threads. Libraries that use rte_lcore_index() to select per-lcore > caches fall back to a shared global path when it returns -1, causing > severe contention under concurrent access from multiple registered > threads. > > A concrete example is the mlx5 indexed memory pool (mlx5_ipool), which > uses rte_lcore_index() in mlx5_ipool_malloc_cache() to select a per-core > cache slot. When core_index is -1, all registered threads are funneled > into a single shared slot protected by a spinlock. In testing with VPP > (which registers worker threads via rte_thread_register()), this caused > async flow rule insertion throughput to drop from ~6.4M rules/sec to > ~1.2M rules/sec with 4 workers -- a 5x regression attributable entirely > to spinlock contention in the ipool allocator. > > Fix by tracking currently allocated core_index values in a bitset and > assigning non-EAL threads the first free index. Keep the bitset in sync > when initial EAL lcores are configured, when EAL core-list parsing > remaps lcores, and when non-EAL registration fails or releases an lcore. > > Fixes: 5c307ba2a5b1 ("eal: register non-EAL threads as lcores") > Signed-off-by: Maxime Peim <[email protected]> > --- > v2: > - Track allocated core_index values with a bitset instead of deriving > the next non-EAL index from lcore_count, avoiding duplicate indices > after non-EAL lcore release. > - Keep the bitset in sync when default EAL lcores are discovered, when > EAL lcore options remap the active set, and when non-EAL lcore > registration rolls back or releases an lcore.
Acked-by: David Marchand <[email protected]> Applied, thanks for this fix Maxime. -- David Marchand
