From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4FDD945B26; Sun, 13 Oct 2024 09:02:44 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C551A402C4; Sun, 13 Oct 2024 09:02:43 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id 8574040151 for ; Sun, 13 Oct 2024 09:02:42 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 14DE5AA11 for ; Sun, 13 Oct 2024 09:02:42 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id F15C0A9CB; Sun, 13 Oct 2024 09:02:41 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=ALL_TRUSTED,AWL, T_SCC_BODY_TEXT_LINE autolearn=disabled version=4.0.0 X-Spam-Score: -1.2 Received: from [192.168.1.85] (h-62-63-215-114.A163.priv.bahnhof.se [62.63.215.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 3A821AA86; Sun, 13 Oct 2024 09:02:38 +0200 (CEST) Message-ID: Date: Sun, 13 Oct 2024 09:02:38 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v10 0/7] Lcore variables To: Stephen Hemminger , =?UTF-8?Q?Mattias_R=C3=B6nnblom?= Cc: dev@dpdk.org, =?UTF-8?Q?Morten_Br=C3=B8rup?= , Konstantin Ananyev , David Marchand , Jerin Jacob , Luka Jankovic References: <20241010142205.813134-2-mattias.ronnblom@ericsson.com> <20241011081901.816211-1-mattias.ronnblom@ericsson.com> <20241011072544.47a041c1@hermes.local> Content-Language: en-US From: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= In-Reply-To: <20241011072544.47a041c1@hermes.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On 2024-10-11 16:25, Stephen Hemminger wrote: > On Fri, 11 Oct 2024 10:18:54 +0200 > Mattias Rönnblom wrote: > >> This patch set introduces a new API for static >> per-lcore id data allocation. >> >> Please refer to the 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.