Hello Maxime, On Tue, 21 Jul 2026 at 10:18, 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 setting core_index to the next sequential index (cfg->lcore_count) > in eal_lcore_non_eal_allocate() before incrementing the count. Also reset > core_index back to -1 on the error rollback path and in > eal_lcore_non_eal_release() for correctness. > > Fixes: 5c307ba2a5 ("eal: register non-EAL threads as lcores") > Fixes: 99c05ce5ef ("eal: parse coremask as cpuset") > 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. > v3: > - Fix commit message to track also 99c05ce5ef
The patch is already merged in main. And we can't really go back in time (for now ;-)), sorry. If you want to highlight one more Fixes:, you may contact LTS maintainers, but nothing more can be done in main. Note: I see you sent the patch with a Reply-to: field where you probably wanted to use In-Reply-To:. It was also the case with the v2 patch iirc. -- David Marchand
