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 5196645B04; Thu, 10 Oct 2024 18:18:04 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D180D402D4; Thu, 10 Oct 2024 18:18:03 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id CD3AB4026B for ; Thu, 10 Oct 2024 18:18:02 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 8FD9A1FFAC for ; Thu, 10 Oct 2024 18:18:02 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 820781FEC3; Thu, 10 Oct 2024 18:18:02 +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 62DEF1FFAB; Thu, 10 Oct 2024 18:17:58 +0200 (CEST) Message-ID: Date: Thu, 10 Oct 2024 18:17:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 1/7] eal: add static per-lcore memory allocation facility 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 , Konstantin Ananyev , Chengwen Feng References: <20241010141349.813088-2-mattias.ronnblom@ericsson.com> <20241010142205.813134-1-mattias.ronnblom@ericsson.com> <20241010142205.813134-2-mattias.ronnblom@ericsson.com> <20241010085420.649d33c4@hermes.local> Content-Language: en-US From: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= In-Reply-To: <20241010085420.649d33c4@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-10 17:54, Stephen Hemminger wrote: > On Thu, 10 Oct 2024 16:21:59 +0200 > Mattias Rönnblom wrote: > >> Introduce DPDK per-lcore id variables, or lcore variables for short. >> >> An lcore variable has one value for every current and future lcore >> id-equipped thread. >> >> The primary use case is for statically allocating >> small, frequently-accessed data structures, for which one instance >> should exist for each lcore. >> >> Lcore variables are similar to thread-local storage (TLS, e.g., C11 >> _Thread_local), but decoupling the values' life time with that of the >> threads. >> >> Lcore variables are also similar in terms of functionality provided by >> FreeBSD kernel's DPCPU_*() family of macros and the associated >> build-time machinery. DPCPU uses linker scripts, which effectively >> prevents the reuse of its, otherwise seemingly viable, approach. >> >> The currently-prevailing way to solve the same problem as lcore >> variables is to keep a module's per-lcore data as RTE_MAX_LCORE-sized >> array of cache-aligned, RTE_CACHE_GUARDed structs. The benefit of >> lcore variables over this approach is that data related to the same >> lcore now is close (spatially, in memory), rather than data used by >> the same module, which in turn avoid excessive use of padding, >> polluting caches with unused data. >> >> Signed-off-by: Mattias Rönnblom >> Acked-by: Morten Brørup >> Acked-by: Konstantin Ananyev >> Acked-by: Chengwen Feng >> Acked-by: Stephen Hemminger > > If you need to send v10, fix this please. > > OK, will do. > > WARNING:TYPO_SPELLING: 'varibles' may be misspelled - perhaps 'variables'? > #336: FILE: doc/guides/prog_guide/env_abstraction_layer.rst:447: > +Lcore varibles are suitable for small object statically allocated at > > WARNING:TYPO_SPELLING: 'identifer' may be misspelled - perhaps 'identifier'? > #867: FILE: lib/eal/include/rte_lcore_var.h:360: > + * The pointer returned is only an opaque identifer of the variable. To I wonder why my checkpatch doesn't spot this, but the DPDK CI version does.