[PATCH v10 0/7] Lcore variables

[Mattias Rönnblom]

On 2024-10-11 16:25, Stephen Hemminger wrote:
> On Fri, 11 Oct 2024 10:18:54 +0200
> Mattias Rönnblom <mattias.ronnblom at 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.