Hi David, Oh sorry, I was contacted by Luca for backporting this patch to 24.11, but I realized that there was a missing patch in the chain for the backport to be valid. I think I'll just drop the backporting then.
(thanks I didn't notice!) On Tue, Jul 21, 2026 at 10:28 AM David Marchand <[email protected]> wrote: > 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 > >
