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 > >> >> >
