|SUCCESS| eal: fix core_index for non-EAL registered threads

[dpdklab at iol.unh.edu]

Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/163286

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-04-24

From: Maxime Peim <maxime.peim at gmail.com>
Date: Wed, 22 Apr 2026 09:54:14 +0200
Subject: [PATCH] eal: fix core_index for non-EAL registered threads

This patch addresses a bug in eal_lcore_non_eal_allocate() where
core_index is left at -1 for non-EAL threads, and updates
eal_lcore_non_eal_release() to reset it properly.

> diff --git a/lib/eal/common/eal_common_lcore.c b/lib/eal/common/eal_common_lcore.c
> index 39411f9370..ae085d73e4 100644
> --- a/lib/eal/common/eal_common_lcore.c
> +++ b/lib/eal/common/eal_common_lcore.c
> @@ -378,6 +378,7 @@ eal_lcore_non_eal_allocate(void)
>  	for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
>  		if (cfg->lcore_role[lcore_id] != ROLE_OFF)
>  			continue;
> +		lcore_config[lcore_id].core_index = cfg->lcore_count;
>  		cfg->lcore_role[lcore_id] = ROLE_NON_EAL;
>  		cfg->lcore_count++;
>  		break;

Does this code handle concurrent calls to eal_lcore_non_eal_allocate()
safely?  If two threads call rte_thread_register() concurrently, could
they both read the same cfg->lcore_count value and assign the same
core_index to different lcore_ids?

The locking comment at the top of this file states:
"All of these functions are called with the eal_lcore_state_lock held."
Does that lock actually protect cfg->lcore_count from concurrent access
in this code path?

> @@ -399,6 +400,7 @@ eal_lcore_non_eal_allocate(void)
>  		}
>  		EAL_LOG(DEBUG, "Initialization refused for lcore %u.",
>  			lcore_id);
> +		lcore_config[lcore_id].core_index = -1;
>  		cfg->lcore_role[lcore_id] = ROLE_OFF;
>  		cfg->lcore_count--;
>  		lcore_id = RTE_MAX_LCORE;

When initialization fails and this rollback happens, does decrementing
cfg->lcore_count restore the correct count if other threads allocated
lcores concurrently?

[ ... ]