> From: Mattias Rönnblom [mailto:mattias.ronnb...@ericsson.com] > Sent: Monday, 6 May 2024 10.27 > > This RFC presents a new API <rte_lcore_var.h> for static per-lcore id > data allocation. > > Please refer to the <rte_lcore_var.h> API documentation for both a > rationale for this new API, and a comparison to the alternatives > available. > > The adoption of this API would affect many different DPDK modules, but > the author updated only a few, mostly to serve as examples in this > RFC, and to iron out some, but surely not all, wrinkles in the API. > > The question on how to best allocate static per-lcore memory has been > up several times on the dev mailing list, for example in the thread on > "random: use per lcore state" RFC by Stephen Hemminger. > > Lcore variables are surely not the answer to all your per-lcore-data > needs, since it only allows for more-or-less static allocation. In the > author's opinion, it does however provide a reasonably simple and > clean and seemingly very much performant solution to a real problem.
This RFC is an improvement of the design pattern of allocating a RTE_MAX_LCORE sized array of structs per library, which typically introduces a lot of padding, and thus wastes L1 data cache. I would like to see it as a patch getting into DPDK 24.11. > > One thing is unclear to the author is how this API relates to a > potential future per-lcore dynamic allocator (e.g., a per-lcore heap). Perfection is the enemy of progress. Let's consider this a 1:1 upgrade of a existing design pattern, and not worry about how to broaden its scope in the future. -Morten
