[PATCH v3] examples/l3fwd: dynamic NUMA-aware alloc lcore_conf

Konstantin Ananyev konstantin.v.ananyev at yandex.ru
Fri Oct 30 11:52:00 CET 2026



> On 10/29/2026 5:19 PM, Konstantin Ananyev wrote:
>>
>>
>>> Currently lcore_conf is a global static array. When multiple
>>> ports/lcores are distributed across different NUMA nodes, datapath
>>> suffers from severe cross-NUMA memory access penalty.
>>>
>>> On Kunpeng platform, sizeof(struct lcore_conf) reaches 133760 bytes.
>>> Such a huge per-lcore structure significantly amplifies cross-NUMA
>>> overhead in multi-port multi-NUMA deployment scenarios.
>>>
>>> This commit refactors lcore_conf to pointer array and implements
>>> per-lcore NUMA-aware hugepage allocation, allocating each lcore's
>>> configuration on its local socket to eliminate remote memory access.
>>>
>>> Signed-off-by: Chengwen Feng <fengchengwen at huawei.com>
>>>
>>> ---
...
>>> +}
>>> +
>>> +static int
>>> +init_lcore_conf(void)
>>> +{
>>> +    unsigned int lcore_id;
>>> +    int socketid;
>>> +
>>> +    for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
>>> +        if (rte_lcore_is_enabled(lcore_id) == 0)
>>> +            continue;
>>> +
>>> +        socketid = numa_on ? rte_lcore_to_socket_id(lcore_id) : 0;
>> Shouldn't it be SOCKET_ID_ANY (-1) instead of zero, when NUMA is disabled?
> OK, already fix in v4
>
> BTW: SOCKET_ID_ANY seemed need redefined as RTE_SOCKET_ID_ANY, If there is no
>       objection, I will make the changes in the next independent patch.

Yep, that's probably a good thing to do, and probably 26.11 is a good 
time to do that.
BTW, I think it was discussed before, but I can't remember why we didn't 
fix it so far.
Konstantin

>
> Thanks,
> Chengwen
>
>


More information about the dev mailing list