> From: Mattias Rönnblom [mailto:[email protected]]
> Sent: Tuesday, 20 February 2024 09.49
>
> Replace static array of cache-aligned structs with an lcore variable,
> to slightly benefit code simplicity and performance.
>
> Signed-off-by: Mattias Rönnblom <[email protected]>
> ---
> @@ -486,8 +489,7 @@ service_runner_func(void *arg)
> {
> RTE_SET_USED(arg);
> uint8_t i;
> - const int lcore = rte_lcore_id();
> - struct core_state *cs = &lcore_states[lcore];
> + struct core_state *cs = RTE_LCORE_VAR_PTR(lcore_states);
Typo: TAB -> SPACE.
>
> rte_atomic_store_explicit(&cs->thread_active, 1,
> rte_memory_order_seq_cst);
>
> @@ -533,13 +535,16 @@ service_runner_func(void *arg)
> int32_t
> rte_service_lcore_may_be_active(uint32_t lcore)
> {
> - if (lcore >= RTE_MAX_LCORE || !lcore_states[lcore].is_service_core)
> + struct core_state *cs =
> + RTE_LCORE_VAR_LCORE_PTR(lcore, lcore_states);
> +
> + if (lcore >= RTE_MAX_LCORE || !cs->is_service_core)
> return -EINVAL;
This comment is mostly related to patch 1 in the series...
You are setting cs = RTE_LCORE_VAR_LCORE_PTR(lcore, ...) before validating that
lcore < RTE_MAX_LCORE. I wondered if that potentially was an overrun bug.
It is obvious when looking at the RTE_LCORE_VAR_LCORE_PTR() macro
implementation, but perhaps its description could mention that it is safe to
use with an "invalid" lcore_id, but not dereferencing it.
