On 2024-10-11 16:25, Stephen Hemminger wrote:
On Fri, 11 Oct 2024 10:18:54 +0200
Mattias Rönnblom <mattias.ronnb...@ericsson.com> wrote:
This patch set introduces 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.
Mattias Rönnblom (7):
eal: add static per-lcore memory allocation facility
eal: add lcore variable functional tests
eal: add lcore variable performance test
random: keep PRNG state in lcore variable
power: keep per-lcore state in lcore variable
service: keep per-lcore state in lcore variable
eal: keep per-lcore power intrinsics state in lcore variable
MAINTAINERS | 6 +
app/test/meson.build | 2 +
app/test/test_lcore_var.c | 436 ++++++++++++++++++
app/test/test_lcore_var_perf.c | 257 +++++++++++
config/rte_config.h | 1 +
doc/api/doxy-api-index.md | 1 +
.../prog_guide/env_abstraction_layer.rst | 43 +-
doc/guides/rel_notes/release_24_11.rst | 14 +
lib/eal/common/eal_common_lcore_var.c | 85 ++++
lib/eal/common/meson.build | 1 +
lib/eal/common/rte_random.c | 28 +-
lib/eal/common/rte_service.c | 117 ++---
lib/eal/include/meson.build | 1 +
lib/eal/include/rte_lcore_var.h | 389 ++++++++++++++++
lib/eal/version.map | 3 +
lib/eal/x86/rte_power_intrinsics.c | 17 +-
lib/power/rte_power_pmd_mgmt.c | 35 +-
17 files changed, 1343 insertions(+), 93 deletions(-)
create mode 100644 app/test/test_lcore_var.c
create mode 100644 app/test/test_lcore_var_perf.c
create mode 100644 lib/eal/common/eal_common_lcore_var.c
create mode 100644 lib/eal/include/rte_lcore_var.h
Are there any trace points in this code? Would be good to have.
No. Yes, for sure.
Also some optional statistics for telemetry use.
I agree. It could potentially expose some of the internals of the
implementation, subject to change, but that is a risk that we can take.
Who does the above two and when? Is this something that is required
before 24.11 (assuming this feature will make it)?
I would presume this is not intended as a hot path API; therefore
it would be ok to always keep statistics.
The allocation functions are expected to be used only in the slowest of
the slow paths.
