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

[fengchengwen <fengchengwen@huawei.com>]

On 11/2/2026 12:13 PM, fengchengwen wrote:
> On 11/1/2026 10:26 PM, Thomas Monjalon wrote:
>> 31/10/2026 02:37, fengchengwen:
>>> On 10/30/2026 8:59 PM, Thomas Monjalon wrote:
>>>> 30/10/2026 11:52, Konstantin Ananyev:
>>>>>> 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.
>>>>
>>>> 1/ We should not break this API easily as it is used a lot.
>>>> If we do the change we need to keep the compat alias for some time.
>>>>
>>>> 2/ The term SOCKET is used in many places instead of NUMA.
>>>> There is a confusion between CPU and memory which deserves to be fixed.
>>>>
>>>
>>> My plan is a 3-patch series:
>>> 1. Add RTE_SOCKET_ID_ANY and deprecation documentation.
>>> 2. Replace all in-tree SOCKET_ID_ANY with RTE_SOCKET_ID_ANY.
>>> 3. Mark SOCKET_ID_ANY with RTE_DEPRECATED after in-tree migration completes,
>>>    so warnings only hit out-of-tree users while DPDK itself builds cleanly.
>>>
>>> I will avoid the bigger "socket -> NUMA node" terminology refactor in this series.
>>> That would be a massive semantic change with large churn, better handled via separate
>>> RFC later.
>>>
>>> If this plan looks acceptable, I will start the implementation.
>>
>> My doubt is that while introducing a new API,
>> it may be better to apply it in correct places with correct definition,
>> avoiding mixing CPU and memory.
> 
> OK, I will try to implement it (avoiding mixing CPU and memory)

I have sent out the full patch series for the tree-wide NUMA terminology
refactor as we briefly discussed. The overall modification scope is
quite large, touching many areas across DPDK.

I understand this brings substantial code churn and API compatibility
concerns. I would appreciate hearing feedback and guidance from the
community on how we should proceed.

Regards,
Chengwen

> 
>>
>>
>