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 1879B45B04; Thu, 10 Oct 2024 17:54:26 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A4973402E6; Thu, 10 Oct 2024 17:54:25 +0200 (CEST) Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com [209.85.210.174]) by mails.dpdk.org (Postfix) with ESMTP id E43DE4026B for ; Thu, 10 Oct 2024 17:54:23 +0200 (CEST) Received: by mail-pf1-f174.google.com with SMTP id d2e1a72fcca58-71dea49e808so972156b3a.1 for ; Thu, 10 Oct 2024 08:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1728575663; x=1729180463; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=Ho6804vWFJ7I4tCKLniCuPjtNyJWYY9ny3Fq0kylUCI=; b=w//7Nij+Dv6GRwJnAghM7bqBU/QrjAPUZwbyDtCKDKxzKv9/Wj01acnz7CTg+cqkO7 jQbtg0k54YG3gt96gHdJydAXq+mGuiCfNhs1bqPa43yRtJhwnbQWqcDXoZAFlk/Jvn1c BlhZHz0P/yPCgFiIDBMJINhtrmx3xie+Af3MtDAPLeCeqjk9v9ILOhM3FEqyhuoVFMLz TCwKLlLfOXvXMjuyrJa7i7Ar+0Lm5ZfcQXzzpkjrcCVmbvO7lNbpiJDcDt+7dn6gjxJ1 PXqB4OLXI/ShexctKXsQR5kJTgfigp5ec69PT6H+kQtFm6ineEHmXI+gtp+PZ64WBQoQ oX/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728575663; x=1729180463; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Ho6804vWFJ7I4tCKLniCuPjtNyJWYY9ny3Fq0kylUCI=; b=u16sSl78blTQoH5M42mi7d3f7Lx+INQZNu7s31jtql8xshW+Z+NQw8uAAyKrKBf8JM KKrPZv1C/iX0yX3SvGlgEBv+GQAsMNLSur0vjzywm4lcvnuA/W0Dj2t0ANsNNmwy8eJV T3u3zR8pygF6FBA1jlDPP/BopWFvWFX+yP7nqVBXlxq4Yzb5ck99M6uwvAvlgtmC39qC dz5mYquYUdHrNpYYan+w4FFW9EHWJccoUfwoGCBwhs5lAfw/QnNKnsjubtfpExqLE1Lp iSr95fe7q3ob2V529MgZjB6Ve+nZXADrIUtcBBNZOssT6hRW8FMrmFTnqGCCxm6K1lY3 +GwA== X-Gm-Message-State: AOJu0Yx8dpeGtP8/txYNmGdbu1JZkEEBG3q0M02Ti9XNCPbmSuRoX/od Kjlz9pCTiMvcujUwaLN0p8AFVLwJqJe0MeBrRhj8kUIZISA5D6uBC99n+bGdHXc= X-Google-Smtp-Source: AGHT+IFqALtkwVOOe/D3ngI9rtRx85QP6dy20WXDJZP1Emx5+J+RsE+CdeZ25SchjcDE0RHaflXAaA== X-Received: by 2002:a05:6a00:1903:b0:71e:cd0:cc99 with SMTP id d2e1a72fcca58-71e1db6ed80mr11694535b3a.4.1728575662827; Thu, 10 Oct 2024 08:54:22 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-71e2ab0b7a1sm1170019b3a.197.2024.10.10.08.54.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Oct 2024 08:54:22 -0700 (PDT) Date: Thu, 10 Oct 2024 08:54:20 -0700 From: Stephen Hemminger To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= Cc: , , Morten =?UTF-8?B?QnLDuHJ1cA==?= , Konstantin Ananyev , David Marchand , Jerin Jacob , Luka Jankovic , Konstantin Ananyev , Chengwen Feng Subject: Re: [PATCH v9 1/7] eal: add static per-lcore memory allocation facility Message-ID: <20241010085420.649d33c4@hermes.local> In-Reply-To: <20241010142205.813134-2-mattias.ronnblom@ericsson.com> References: <20241010141349.813088-2-mattias.ronnblom@ericsson.com> <20241010142205.813134-1-mattias.ronnblom@ericsson.com> <20241010142205.813134-2-mattias.ronnblom@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 Thu, 10 Oct 2024 16:21:59 +0200 Mattias R=C3=B6nnblom wrote: > Introduce DPDK per-lcore id variables, or lcore variables for short. >=20 > An lcore variable has one value for every current and future lcore > id-equipped thread. >=20 > The primary use case is for statically allocating > small, frequently-accessed data structures, for which one instance > should exist for each lcore. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Signed-off-by: Mattias R=C3=B6nnblom > Acked-by: Morten Br=C3=B8rup > Acked-by: Konstantin Ananyev > Acked-by: Chengwen Feng > Acked-by: Stephen Hemminger If you need to send v10, fix this please. 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