<div dir="ltr">Hi David,<br><br><div>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.</div><div>I think I'll just drop the backporting then.</div><div><br></div><div>(thanks I didn't notice!)</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Jul 21, 2026 at 10:28 AM David Marchand <<a href="mailto:david.marchand@redhat.com">david.marchand@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Maxime,<br>
<br>
On Tue, 21 Jul 2026 at 10:18, Maxime Peim <<a href="mailto:maxime.peim@gmail.com" target="_blank">maxime.peim@gmail.com</a>> wrote:<br>
><br>
> Threads registered via rte_thread_register() are assigned a valid<br>
> lcore_id by eal_lcore_non_eal_allocate(), but their core_index in<br>
> lcore_config is left at -1. This value was set during rte_eal_cpu_init()<br>
> for lcores with ROLE_OFF (undetected CPUs) and is never updated when the<br>
> lcore is later allocated to a non-EAL thread.<br>
><br>
> As a result, rte_lcore_index() returns -1 for registered non-EAL<br>
> threads. Libraries that use rte_lcore_index() to select per-lcore<br>
> caches fall back to a shared global path when it returns -1, causing<br>
> severe contention under concurrent access from multiple registered<br>
> threads.<br>
><br>
> A concrete example is the mlx5 indexed memory pool (mlx5_ipool), which<br>
> uses rte_lcore_index() in mlx5_ipool_malloc_cache() to select a per-core<br>
> cache slot. When core_index is -1, all registered threads are funneled<br>
> into a single shared slot protected by a spinlock. In testing with VPP<br>
> (which registers worker threads via rte_thread_register()), this caused<br>
> async flow rule insertion throughput to drop from ~6.4M rules/sec to<br>
> ~1.2M rules/sec with 4 workers -- a 5x regression attributable entirely<br>
> to spinlock contention in the ipool allocator.<br>
><br>
> Fix by setting core_index to the next sequential index (cfg->lcore_count)<br>
> in eal_lcore_non_eal_allocate() before incrementing the count. Also reset<br>
> core_index back to -1 on the error rollback path and in<br>
> eal_lcore_non_eal_release() for correctness.<br>
><br>
> Fixes: 5c307ba2a5 ("eal: register non-EAL threads as lcores")<br>
> Fixes: 99c05ce5ef ("eal: parse coremask as cpuset")<br>
> Signed-off-by: Maxime Peim <<a href="mailto:maxime.peim@gmail.com" target="_blank">maxime.peim@gmail.com</a>><br>
> ---<br>
> v2:<br>
>   - Track allocated core_index values with a bitset instead of deriving<br>
>     the next non-EAL index from lcore_count, avoiding duplicate indices<br>
>     after non-EAL lcore release.<br>
>   - Keep the bitset in sync when default EAL lcores are discovered, when<br>
>     EAL lcore options remap the active set, and when non-EAL lcore<br>
>     registration rolls back or releases an lcore.<br>
> v3:<br>
>   - Fix commit message to track also 99c05ce5ef<br>
<br>
The patch is already merged in main.<br>
And we can't really go back in time (for now ;-)), sorry.<br>
If you want to highlight one more Fixes:, you may contact LTS<br>
maintainers, but nothing more can be done in main.<br>
<br>
Note: I see you sent the patch with a Reply-to: field where you<br>
probably wanted to use In-Reply-To:.<br>
It was also the case with the v2 patch iirc.<br>
<br>
<br>
-- <br>
David Marchand<br>
<br>
</blockquote></div>