Re: [PATCH v3] eal: fix core_index for non-EAL registered threads

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
>
>