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 5DC0245BAE; Wed, 23 Oct 2024 10:07:44 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2D27E4065B; Wed, 23 Oct 2024 10:07:44 +0200 (CEST) Received: from EUR02-VI1-obe.outbound.protection.outlook.com (mail-vi1eur02on2067.outbound.protection.outlook.com [40.107.241.67]) by mails.dpdk.org (Postfix) with ESMTP id 669DE402E4 for ; Wed, 23 Oct 2024 10:07:43 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=q2qAlaqrxgnoBcY2cOz9NV+xLHr9tnJ/67NRzupEyMA624CGZNYAZ380rPlhA7aI5ckel4d7De8JR0ZHsr701dVC38sXY8fNGeHHUfYY6AaiBa6PZ5CkIyCuJtqQwjFzPw2jtPgk8Wk0AHdVcj1TGZTOXcfVTUBnwgsNFB/xJ8Tm7BJFTGiahUbgLeSeMsBzIcmS7J+OnwyYi0+tRfxGD3rnutWe/oBrIB/f6TvlTgPU/kW6XF/nhU+Di0zImNf2DAv5OcjE7co4U9uVIl+nqF/0eCfHR9/8+lGGBHEHCK23IwWsExOkmb19j7jy9NqncNlc1y8bhbj4mori5A0bpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8yM6avLBJJrKcQiXwQTlPCj+O8y63yG32NdiRa/QrZk=; b=EpoCU+oSHjuSKWdVF4rDgspxSihiLhddqVHPJ5gBvBqDBWtP00Xj6Koc4A7qkv9+Kymuj/aNOT/Sv3L5qJzgGx635FCR595CworzJYcUov3iGUwPcIpfoq/HGJe0PSLcvIaOnv2OiY5oEMOD2bIojRd1Dm5sZGvnBcn9LHo4Q47lF/rCttTC2vboFukjZRkZNFVTakFRJ+ofKE+5d1Zyw4oXLwFyftzFBie3+Sw2WRjF8SjscMkBg3RFeFyMzpJE2jk8rWz9EoldED6ANprATm+iEV0wsHY3V5AnYhejaz9bYxpfyIgFRb+WizysDv44qgk0WZCBx9LCqn9RotvnvA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 192.176.1.74) smtp.rcpttodomain=dpdk.org smtp.mailfrom=ericsson.com; dmarc=pass (p=reject sp=reject pct=100) action=none header.from=ericsson.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8yM6avLBJJrKcQiXwQTlPCj+O8y63yG32NdiRa/QrZk=; b=R1PBemDa3tmXQYx2G7A/wbpQhU5YRVtgO1oyq+erTritLbZPTpwQGac5+4AKOSeaQeJs5jGlsGdQtAaGoR4zcaUyfXrItBEaJR9nqyNtlfyC5UqHAAIZPsSlaBLz+uLASToYzwJmP45yzIgD7/XkoJ88apK5d0BhL4+UFlD168BYC0y44dt4QjgWsYekSrvyAYsERKwN++d6BE8HZQpZYr5nMFnlR8+/nQlrr4DSxEKFTtQXOHG6eUGAB6KBWFUVgrctizvGqiate/Lc/p/xsY0mpEUc8PRtHYC7/saD/GmQrwE5VMKbhz4RlR5WhGM9x+waSf2pEpq2GFmiSFgI+w== Received: from AS4P191CA0045.EURP191.PROD.OUTLOOK.COM (2603:10a6:20b:657::28) by DU0PR07MB8972.eurprd07.prod.outlook.com (2603:10a6:10:40c::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8093.17; Wed, 23 Oct 2024 08:07:38 +0000 Received: from AM2PEPF0001C710.eurprd05.prod.outlook.com (2603:10a6:20b:657:cafe::3e) by AS4P191CA0045.outlook.office365.com (2603:10a6:20b:657::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8093.16 via Frontend Transport; Wed, 23 Oct 2024 08:07:38 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 192.176.1.74) smtp.mailfrom=ericsson.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=ericsson.com; Received-SPF: Pass (protection.outlook.com: domain of ericsson.com designates 192.176.1.74 as permitted sender) receiver=protection.outlook.com; client-ip=192.176.1.74; helo=oa.msg.ericsson.com; pr=C Received: from oa.msg.ericsson.com (192.176.1.74) by AM2PEPF0001C710.mail.protection.outlook.com (10.167.16.180) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8093.14 via Frontend Transport; Wed, 23 Oct 2024 08:07:38 +0000 Received: from seliicinfr00049.seli.gic.ericsson.se (153.88.142.248) by smtp-central.internal.ericsson.com (100.87.178.62) with Microsoft SMTP Server id 15.2.1544.11; Wed, 23 Oct 2024 10:07:37 +0200 Received: from breslau.. (seliicwb00002.seli.gic.ericsson.se [10.156.25.100]) by seliicinfr00049.seli.gic.ericsson.se (Postfix) with ESMTP id 083EC3800B9; Wed, 23 Oct 2024 10:02:03 +0200 (CEST) From: =?UTF-8?q?Mattias=20R=C3=B6nnblom?= To: CC: , =?UTF-8?q?Morten=20Br=C3=B8rup?= , Stephen Hemminger , Konstantin Ananyev , David Marchand , Jerin Jacob , Luka Jankovic , Thomas Monjalon , =?UTF-8?q?Mattias=20R=C3=B6nnblom?= , Konstantin Ananyev , Chengwen Feng Subject: [PATCH v16 1/8] eal: add static per-lcore memory allocation facility Date: Wed, 23 Oct 2024 09:52:55 +0200 Message-ID: <20241023075302.869008-2-mattias.ronnblom@ericsson.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241023075302.869008-1-mattias.ronnblom@ericsson.com> References: <20241017055743.848292-1-mattias.ronnblom@ericsson.com> <20241023075302.869008-1-mattias.ronnblom@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM2PEPF0001C710:EE_|DU0PR07MB8972:EE_ X-MS-Office365-Filtering-Correlation-Id: 0295e4d1-44d4-4af8-453b-08dcf339c29d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; ARA:13230040|1800799024|7416014|36860700013|376014|82310400026; X-Microsoft-Antispam-Message-Info: =?utf-8?B?TmFCQXdyK0pPREN3cmEyaVAybFRQOERkM1p3NFN5YjArdjlKZTA4enVaSHky?= =?utf-8?B?OTNiOXdNditjOHYraFhSNVd0VmcxZ1hHZEhkaElGTUkrUStmL054dWkwNVpz?= =?utf-8?B?Z3hUQVVyenpZY243YVVxcURJL1JuNGhHLzlJb2lOUjhMY244djFTUkhSQ21y?= =?utf-8?B?R1hiT25BcUNXdDk1SnYzSlRoMkpjT3ZTT2o4WTIyZHNIVGFuRVUxUDNkZUxE?= =?utf-8?B?aXVlejNkZWUrTUE5YzBDTUorLzRPRXQ2dHJpQnd2VGRsalBSazMxWXplWnZS?= =?utf-8?B?NkhSbVlzQSttZzFuNXFrTHJmZVZldk9vNm5ISlFzOXBhSUhWUStHUmZZbGtP?= =?utf-8?B?dGNPM09JWDVDTlRDeFdhUjJ1WFFPb1d2ZFRTY1FiOGdLT0QreDE3T2tVVjZh?= =?utf-8?B?T0lOYmpGRHBhUDdQRFRvejhOQjNpVmxXS2hIWWtLanJtNWplRGVuN2llNG1y?= =?utf-8?B?dXlRbTFlNVVxd1UrbDlHb09YeFk0ejE3bnJkdFdCSGViMzBnRlJ0c1hyV083?= =?utf-8?B?ME8xT3pFSlUvc0VwVHcwejlNOGt2RSt4dHphNytGSjN5Y2tsTUkwVndiRnMr?= =?utf-8?B?MXZyUnV2M3duWHNUNmNtYkJ0N0huM1FXUTdQeTgyOWtCb1ZWbTRidkNhT0JC?= =?utf-8?B?VlZQbDN2YWVDV0RST2hheTJkVjRHUG80RWNTaXhmQWxveVFlVXowZzlDUkVl?= =?utf-8?B?R3M1T1ZCcFBmY0t6U25hWW9FYTdTZERsS3ludkZjN3ozcHk0U1drQ0RaeWow?= =?utf-8?B?ektRTXBhbkF0WXB2VVZ1bkdtKzkrL0IvTkd4V1ZlaGdjZS9jQXcvc3N0b1Qx?= =?utf-8?B?VW1PS3NxbFN2Mitja0R2a1B6bWc2WGVuU01Ma3o2d0l5WGRUelg3VTVJS0xY?= =?utf-8?B?d0JPdmlvZGVzOFFsY1pLS0JOdWFvWDNLNXNqUzhUVVlwNG43dDdtKzFCNzAx?= =?utf-8?B?MXAzcWZONlN1UDArUERSMHlGc011eUwxaCtaeEpCV1prOVJmTFB5eXB5TnYv?= =?utf-8?B?WituSjdLUGtaTGZTd1JZSHYrRG45TWRzT2JUenZYM3lWQ0RrVzk0UlBCNk12?= =?utf-8?B?S3YrN1lFc3FaWUluYjdibUQzMFdMRkxHVm93ZUtoaUFpWGdad2dXbFRMZnlm?= =?utf-8?B?Vlo5OEl2Mk9nQlFVeE9aSnpkRldPVG9GK3BMbks4VXRvV3pSOEVXdHpmZUlt?= =?utf-8?B?RTNNdUMrbVBRUXdoOFRpczNVM1llUHk3ekIvTGxIY240c051OVBFeUNKUlFs?= =?utf-8?B?MjdUOThlZStleEdhNzY1SU90dW5hc3IzMWlkMmJ4VHVCcURPZWhFNXY3b3NW?= =?utf-8?B?N2VENU9sODE4cGRDTGFCaGVOWkVIUW0rTFpEa21kMHpjU0x0MG5KZTlrb3cw?= =?utf-8?B?cVRyeHR5OFpMRTBYbWoxNi8wVWgzbkxZRE44MldyZEc4THdkbU1ZREVibUc3?= =?utf-8?B?Q3U2L3lVOXlPWWFweUtVOGpSWExYYy9FeHZvOU1idjNIeGJBcnZEKzBETXFH?= =?utf-8?B?WEdzR1hZOFc3THZsRjlBeUQyVzg1UDdXdTJ5c1VhQ2wweU9vdFlzOUpuMzZV?= =?utf-8?B?eFhPa25IczRpSnR4M0VZbXhyMTFVRlh1Vk5kNW5qZG1MVmNkL3A5ZVdoRjBv?= =?utf-8?B?anQwMmpCTWlZZHp0bG5RRFJDcFBxSDZqbTFnSHhuOVNRL0NYYWoyNGJ5b0lo?= =?utf-8?B?aEdrRjVuVjlSdUNQdEtJTHJhd21CRWMzb0g1b3hUcUlqMUZRRDEySXBWQkE5?= =?utf-8?B?SCtxcWpTYzdDQkJmekVCbmU0ck8ybGp6K01HTENlOXkwcTRtbWNwQ0syM1h2?= =?utf-8?B?aWlpUC82NTdrNTFEMTAvNXRSL0V6anJMQVV1Yk1oaGduYlkvZ254MEc4SVo0?= =?utf-8?B?SjFHS3RBTE9WWGgvVVBiNjZrL2pzN0ltWWd4RDJmSTBCSGc9PQ==?= X-Forefront-Antispam-Report: CIP:192.176.1.74; CTRY:SE; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:oa.msg.ericsson.com; PTR:office365.se.ericsson.net; CAT:NONE; SFS:(13230040)(1800799024)(7416014)(36860700013)(376014)(82310400026); DIR:OUT; SFP:1101; X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2024 08:07:38.3071 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0295e4d1-44d4-4af8-453b-08dcf339c29d X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=92e84ceb-fbfd-47ab-be52-080c6b87953f; Ip=[192.176.1.74]; Helo=[oa.msg.ericsson.com] X-MS-Exchange-CrossTenant-AuthSource: AM2PEPF0001C710.eurprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR07MB8972 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 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 -- PATCH v16: * Move implementation overview type information to the programmer's guide. PATCH v15: * Add alignment-related compiler hint. (Stephen Hemminger) * Have size-related compiler hint point toward the right function argument. (Stephen Hemminger) PATCH v14: * Add note in rte_lcore_var_alloc() that the memory cannot be freed. (Stephen Hemminger) * Hint the compiler rte_lcore_var_alloc() is a memory allocation facility. (Stephen Hemminger) PATCH v13: * Remove _VALUE() suffix from value lookup and iterator macros. (Morten Brørup and Thomas Monjalon) * Remove the _ptr() suffix from the value lookup function. PATCH v12: * Replace RTE_ASSERT() with RTE_VERIFY(), since performance is not a concern. (Morten Brørup) * Fix issue (introduced in v11) where aligned_malloc() was provided an object size which wasn't an even number of the alignment. (Stephen Hemminger) PATCH v11: * Add a note in the API docs on lcore variables and huge page memory. (Stephen Hemminger) * Free lcore var buffers at EAL cleanup. (Thomas Monjalon) * Tweak naming and include short lcore var buffer use overview in eal_common_lcore_var.c. PATCH v10: * Improve documentation grammar and spelling. (Stephen Hemminger, Thomas Monjalon) * Add version.map DPDK version comment. (Thomas Monjalon) PATCH v9: * Fixed merge conflicts in release notes. PATCH v8: * Work around missing max_align_t definition in MSVC. (Morten Brørup) PATCH v7: * Add () to the FOREACH lcore id macro parameter, to allow arbitrary expression, not just a simple variable name, being passed. (Konstantin Ananyev) PATCH v6: * Have API user provide the loop variable in the FOREACH macro, to avoid subtle bugs where the loop variable name clashes with some other user-defined variable. (Konstantin Ananyev) PATCH v5: * Update EAL programming guide. PATCH v2: * Add Windows support. (Morten Brørup) * Fix lcore variables API index reference. (Morten Brørup) * Various improvements of the API documentation. (Morten Brørup) * Elimination of unused symbol in version.map. (Morten Brørup) PATCH: * Update MAINTAINERS and release notes. * Stop covering included files in extern "C" {}. RFC v6: * Include to get aligned_alloc(). * Tweak documentation (grammar). * Provide API-level guarantees that lcore variable values take on an initial value of zero. * Fix misplaced __rte_cache_aligned in the API doc example. RFC v5: * In Doxygen, consistenly use @ (and not \). * The RTE_LCORE_VAR_GET() and SET() convience access macros covered an uncommon use case, where the lcore value is of a primitive type, rather than a struct, and is thus eliminated from the API. (Morten Brørup) * In the wake up GET()/SET() removeal, rename RTE_LCORE_VAR_PTR() RTE_LCORE_VAR_VALUE(). * The underscores are removed from __rte_lcore_var_lcore_ptr() to signal that this function is a part of the public API. * Macro arguments are documented. RFV v4: * Replace large static array with libc heap-allocated memory. One implication of this change is there no longer exists a fixed upper bound for the total amount of memory used by lcore variables. RTE_MAX_LCORE_VAR has changed meaning, and now represent the maximum size of any individual lcore variable value. * Fix issues in example. (Morten Brørup) * Improve access macro type checking. (Morten Brørup) * Refer to the lcore variable handle as "handle" and not "name" in various macros. * Document lack of thread safety in rte_lcore_var_alloc(). * Provide API-level assurance the lcore variable handle is always non-NULL, to all applications to use NULL to mean "not yet allocated". * Note zero-sized allocations are not allowed. * Give API-level guarantee the lcore variable values are zeroed. RFC v3: * Replace use of GCC-specific alignof() with alignof(). * Update example to reflect FOREACH macro name change (in RFC v2). RFC v2: * Use alignof to derive alignment requirements. (Morten Brørup) * Change name of FOREACH to make it distinct from 's *per-EAL-thread* RTE_LCORE_FOREACH(). (Morten Brørup) * Allow user-specified alignment, but limit max to cache line size. --- MAINTAINERS | 6 + 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 | 112 ++++++++++ lib/eal/common/eal_lcore_var.h | 11 + lib/eal/common/meson.build | 1 + lib/eal/freebsd/eal.c | 2 + lib/eal/include/meson.build | 1 + lib/eal/include/rte_lcore_var.h | 207 ++++++++++++++++++ lib/eal/linux/eal.c | 2 + lib/eal/version.map | 1 + 13 files changed, 396 insertions(+), 6 deletions(-) create mode 100644 lib/eal/common/eal_common_lcore_var.c create mode 100644 lib/eal/common/eal_lcore_var.h create mode 100644 lib/eal/include/rte_lcore_var.h diff --git a/MAINTAINERS b/MAINTAINERS index 6ea7850093..557474a38b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -289,6 +289,12 @@ F: lib/eal/include/rte_random.h F: lib/eal/common/rte_random.c F: app/test/test_rand_perf.c +Lcore Variables +M: Mattias Rönnblom +F: lib/eal/include/rte_lcore_var.h +F: lib/eal/common/eal_common_lcore_var.c +F: app/test/test_lcore_var.c + ARM v7 M: Wathsala Vithanage F: config/arm/ diff --git a/config/rte_config.h b/config/rte_config.h index fd6f8a2f1a..498d509244 100644 --- a/config/rte_config.h +++ b/config/rte_config.h @@ -41,6 +41,7 @@ /* EAL defines */ #define RTE_CACHE_GUARD_LINES 1 #define RTE_MAX_HEAPS 32 +#define RTE_MAX_LCORE_VAR 1048576 #define RTE_MAX_MEMSEG_LISTS 128 #define RTE_MAX_MEMSEG_PER_LIST 8192 #define RTE_MAX_MEM_MB_PER_LIST 32768 diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md index 266c8b90dc..1d472c6ceb 100644 --- a/doc/api/doxy-api-index.md +++ b/doc/api/doxy-api-index.md @@ -99,6 +99,7 @@ The public API headers are grouped by topics: [interrupts](@ref rte_interrupts.h), [launch](@ref rte_launch.h), [lcore](@ref rte_lcore.h), + [lcore variables](@ref rte_lcore_var.h), [per-lcore](@ref rte_per_lcore.h), [service cores](@ref rte_service.h), [keepalive](@ref rte_keepalive.h), diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst index b9fac1839d..b659a1d085 100644 --- a/doc/guides/prog_guide/env_abstraction_layer.rst +++ b/doc/guides/prog_guide/env_abstraction_layer.rst @@ -429,12 +429,43 @@ with them once they're registered. Per-lcore and Shared Variables ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -.. note:: - - lcore refers to a logical execution unit of the processor, sometimes called a hardware *thread*. - -Shared variables are the default behavior. -Per-lcore variables are implemented using *Thread Local Storage* (TLS) to provide per-thread local storage. +By default, static variables, memory blocks allocated on the DPDK +heap, and other types of memory are shared by all DPDK threads. + +An application, a DPDK library, or a PMD may opt to keep per-thread state. + +Per-thread data can be maintained using either *lcore variables* (see +``rte_lcore_var.h``), *thread-local storage (TLS)* (see +``rte_per_lcore.h``), or a static array of ``RTE_MAX_LCORE`` elements, +indexed by ``rte_lcore_id()``. These methods allow per-lcore data to be +largely internal to the module and not directly exposed in its +API. Another approach is to explicitly handle per-thread aspects in +the API (e.g., the ports in the Eventdev API). + +Lcore variables are suitable for small objects that are statically +allocated at the time of module or application initialization. An +lcore variable takes on one value for each lcore ID-equipped thread +(i.e., for both EAL threads and registered non-EAL threads, in total +``RTE_MAX_LCORE`` instances). The lifetime of lcore variables is +independent of the owning threads and can, therefore, be initialized +before the threads are created. + +Variables with thread-local storage are allocated when the thread is +created and exist until the thread terminates. These are applicable +for every thread in the process. Only very small objects should be +allocated in TLS, as large TLS objects can significantly slow down +thread creation and may unnecessarily increase the memory footprint of +applications that extensively use unregistered threads. + +A common but now largely obsolete DPDK pattern is to use a static +array sized according to the maximum number of lcore ID-equipped +threads (i.e., with ``RTE_MAX_LCORE`` elements). To avoid *false +sharing*, each element must be both cache-aligned and include an +``RTE_CACHE_GUARD``. This extensive use of padding causes internal +fragmentation (i.e., unused space) and reduces cache hit rates. + +For more discussions on per-lcore state, refer to the +``rte_lcore_var.h`` API documentation. Logs ~~~~ diff --git a/doc/guides/rel_notes/release_24_11.rst b/doc/guides/rel_notes/release_24_11.rst index fa4822d928..18f2f37944 100644 --- a/doc/guides/rel_notes/release_24_11.rst +++ b/doc/guides/rel_notes/release_24_11.rst @@ -247,6 +247,20 @@ New Features Added ability for node to advertise and update multiple xstat counters, that can be retrieved using ``rte_graph_cluster_stats_get``. +* **Added EAL per-lcore static memory allocation facility.** + + Added EAL API for statically allocating small, + frequently-accessed data structures, for which one instance should + exist for each EAL thread and registered non-EAL thread. + + With lcore variables, data is organized spatially on a per-lcore id + basis, rather than per library or PMD, avoiding the need for cache + aligning (or RTE_CACHE_GUARDing) data structures, which in turn + reduces CPU cache internal fragmentation, improving performance. + + Lcore variables are similar to thread-local storage (TLS, e.g., + C11 _Thread_local), but decoupling the values' life time from that + of the threads. Removed Items ------------- diff --git a/lib/eal/common/eal_common_lcore_var.c b/lib/eal/common/eal_common_lcore_var.c new file mode 100644 index 0000000000..3b0e0b89f7 --- /dev/null +++ b/lib/eal/common/eal_common_lcore_var.c @@ -0,0 +1,112 @@ +/* SPDX-License-Identifier: BSD-3-Clause + * Copyright(c) 2024 Ericsson AB + */ + +#include +#include + +#ifdef RTE_EXEC_ENV_WINDOWS +#include +#endif + +#include +#include +#include + +#include + +#include "eal_private.h" +#include "eal_lcore_var.h" + +/* + * Refer to the programmer's guide for an overview of the lcore + * variables implementation. + */ + +struct lcore_var_buffer { + char data[RTE_MAX_LCORE_VAR * RTE_MAX_LCORE]; + struct lcore_var_buffer *prev; +}; + +static struct lcore_var_buffer *current_buffer; + +/* initialized to trigger buffer allocation on first allocation */ +static size_t offset = RTE_MAX_LCORE_VAR; + +static void * +lcore_var_alloc(size_t size, size_t align) +{ + void *handle; + unsigned int lcore_id; + void *value; + + offset = RTE_ALIGN_CEIL(offset, align); + + if (offset + size > RTE_MAX_LCORE_VAR) { + struct lcore_var_buffer *prev = current_buffer; + size_t alloc_size = + RTE_ALIGN_CEIL(sizeof(struct lcore_var_buffer), + RTE_CACHE_LINE_SIZE); +#ifdef RTE_EXEC_ENV_WINDOWS + current_buffer = _aligned_malloc(alloc_size, RTE_CACHE_LINE_SIZE); +#else + current_buffer = aligned_alloc(RTE_CACHE_LINE_SIZE, alloc_size); + +#endif + RTE_VERIFY(current_buffer != NULL); + + current_buffer->prev = prev; + + offset = 0; + } + + handle = ¤t_buffer->data[offset]; + + offset += size; + + RTE_LCORE_VAR_FOREACH(lcore_id, value, handle) + memset(value, 0, size); + + EAL_LOG(DEBUG, "Allocated %"PRIuPTR" bytes of per-lcore data with a " + "%"PRIuPTR"-byte alignment", size, align); + + return handle; +} + +void * +rte_lcore_var_alloc(size_t size, size_t align) +{ + /* Having the per-lcore buffer size aligned on cache lines + * assures as well as having the base pointer aligned on cache + * size assures that aligned offsets also translate to aligned + * pointers across all values. + */ + RTE_BUILD_BUG_ON(RTE_MAX_LCORE_VAR % RTE_CACHE_LINE_SIZE != 0); + RTE_VERIFY(align <= RTE_CACHE_LINE_SIZE); + RTE_VERIFY(size <= RTE_MAX_LCORE_VAR); + + /* '0' means asking for worst-case alignment requirements */ + if (align == 0) +#ifdef RTE_TOOLCHAIN_MSVC + /* MSVC is missing the max_align_t typedef */ + align = alignof(double); +#else + align = alignof(max_align_t); +#endif + + RTE_VERIFY(rte_is_power_of_2(align)); + + return lcore_var_alloc(size, align); +} + +void +eal_lcore_var_cleanup(void) +{ + while (current_buffer != NULL) { + struct lcore_var_buffer *prev = current_buffer->prev; + + free(current_buffer); + + current_buffer = prev; + } +} diff --git a/lib/eal/common/eal_lcore_var.h b/lib/eal/common/eal_lcore_var.h new file mode 100644 index 0000000000..de2c4e44a0 --- /dev/null +++ b/lib/eal/common/eal_lcore_var.h @@ -0,0 +1,11 @@ +/* SPDX-License-Identifier: BSD-3-Clause + * Copyright(C) 2024 Ericsson AB. + */ + +#ifndef EAL_LCORE_VAR_H +#define EAL_LCORE_VAR_H + +void +eal_lcore_var_cleanup(void); + +#endif diff --git a/lib/eal/common/meson.build b/lib/eal/common/meson.build index c1bbf26654..e273745e93 100644 --- a/lib/eal/common/meson.build +++ b/lib/eal/common/meson.build @@ -18,6 +18,7 @@ sources += files( 'eal_common_interrupts.c', 'eal_common_launch.c', 'eal_common_lcore.c', + 'eal_common_lcore_var.c', 'eal_common_mcfg.c', 'eal_common_memalloc.c', 'eal_common_memory.c', diff --git a/lib/eal/freebsd/eal.c b/lib/eal/freebsd/eal.c index 1229230063..796c9dbf2d 100644 --- a/lib/eal/freebsd/eal.c +++ b/lib/eal/freebsd/eal.c @@ -47,6 +47,7 @@ #include "eal_private.h" #include "eal_thread.h" +#include "eal_lcore_var.h" #include "eal_internal_cfg.h" #include "eal_filesystem.h" #include "eal_hugepages.h" @@ -941,6 +942,7 @@ rte_eal_cleanup(void) /* after this point, any DPDK pointers will become dangling */ rte_eal_memory_detach(); eal_cleanup_config(internal_conf); + eal_lcore_var_cleanup(); return 0; } diff --git a/lib/eal/include/meson.build b/lib/eal/include/meson.build index 474097f211..d903577caa 100644 --- a/lib/eal/include/meson.build +++ b/lib/eal/include/meson.build @@ -28,6 +28,7 @@ headers += files( 'rte_keepalive.h', 'rte_launch.h', 'rte_lcore.h', + 'rte_lcore_var.h', 'rte_lock_annotations.h', 'rte_malloc.h', 'rte_mcslock.h', diff --git a/lib/eal/include/rte_lcore_var.h b/lib/eal/include/rte_lcore_var.h new file mode 100644 index 0000000000..ea8b61cf7d --- /dev/null +++ b/lib/eal/include/rte_lcore_var.h @@ -0,0 +1,207 @@ +/* SPDX-License-Identifier: BSD-3-Clause + * Copyright(c) 2024 Ericsson AB + */ + +#ifndef _RTE_LCORE_VAR_H_ +#define _RTE_LCORE_VAR_H_ + +/** + * @file + * + * Lcore variables + * + * This API provides a mechanism to create and access per-lcore id + * variables in a space- and cycle-efficient manner. + * + * Please refer to the lcore variables' programmer's guide for an + * overview of this API and its implementation. + */ + +#include +#include + +#include +#include +#include + +#ifdef __cplusplus +extern "C" { +#endif + +/** + * Given the lcore variable type, produces the type of the lcore + * variable handle. + */ +#define RTE_LCORE_VAR_HANDLE_TYPE(type) \ + type * + +/** + * Define an lcore variable handle. + * + * This macro defines a variable which is used as a handle to access + * the various instances of a per-lcore id variable. + * + * This macro clarifies that the declaration is an lcore handle, not a + * regular pointer. + * + * Add @b static as a prefix in case the lcore variable is only to be + * accessed from a particular translation unit. + */ +#define RTE_LCORE_VAR_HANDLE(type, name) \ + RTE_LCORE_VAR_HANDLE_TYPE(type) name + +/** + * Allocate space for an lcore variable, and initialize its handle. + * + * The values of the lcore variable are initialized to zero. + */ +#define RTE_LCORE_VAR_ALLOC_SIZE_ALIGN(handle, size, align) \ + handle = rte_lcore_var_alloc(size, align) + +/** + * Allocate space for an lcore variable, and initialize its handle, + * with values aligned for any type of object. + * + * The values of the lcore variable are initialized to zero. + */ +#define RTE_LCORE_VAR_ALLOC_SIZE(handle, size) \ + RTE_LCORE_VAR_ALLOC_SIZE_ALIGN(handle, size, 0) + +/** + * Allocate space for an lcore variable of the size and alignment requirements + * suggested by the handle pointer type, and initialize its handle. + * + * The values of the lcore variable are initialized to zero. + */ +#define RTE_LCORE_VAR_ALLOC(handle) \ + RTE_LCORE_VAR_ALLOC_SIZE_ALIGN(handle, sizeof(*(handle)), \ + alignof(typeof(*(handle)))) + +/** + * Allocate an explicitly-sized, explicitly-aligned lcore variable by + * means of a @ref RTE_INIT constructor. + * + * The values of the lcore variable are initialized to zero. + */ +#define RTE_LCORE_VAR_INIT_SIZE_ALIGN(name, size, align) \ + RTE_INIT(rte_lcore_var_init_ ## name) \ + { \ + RTE_LCORE_VAR_ALLOC_SIZE_ALIGN(name, size, align); \ + } + +/** + * Allocate an explicitly-sized lcore variable by means of a @ref + * RTE_INIT constructor. + * + * The values of the lcore variable are initialized to zero. + */ +#define RTE_LCORE_VAR_INIT_SIZE(name, size) \ + RTE_LCORE_VAR_INIT_SIZE_ALIGN(name, size, 0) + +/** + * Allocate an lcore variable by means of a @ref RTE_INIT constructor. + * + * The values of the lcore variable are initialized to zero. + */ +#define RTE_LCORE_VAR_INIT(name) \ + RTE_INIT(rte_lcore_var_init_ ## name) \ + { \ + RTE_LCORE_VAR_ALLOC(name); \ + } + +/** + * Get void pointer to lcore variable instance with the specified + * lcore id. + * + * @param lcore_id + * The lcore id specifying which of the @c RTE_MAX_LCORE value + * instances should be accessed. The lcore id need not be valid + * (e.g., may be @ref LCORE_ID_ANY), but in such a case, the pointer + * is also not valid (and thus should not be dereferenced). + * @param handle + * The lcore variable handle. + */ +static inline void * +rte_lcore_var_lcore(unsigned int lcore_id, void *handle) +{ + return RTE_PTR_ADD(handle, lcore_id * RTE_MAX_LCORE_VAR); +} + +/** + * Get pointer to lcore variable instance with the specified lcore id. + * + * @param lcore_id + * The lcore id specifying which of the @c RTE_MAX_LCORE value + * instances should be accessed. The lcore id need not be valid + * (e.g., may be @ref LCORE_ID_ANY), but in such a case, the pointer + * is also not valid (and thus should not be dereferenced). + * @param handle + * The lcore variable handle. + */ +#define RTE_LCORE_VAR_LCORE(lcore_id, handle) \ + ((typeof(handle))rte_lcore_var_lcore(lcore_id, handle)) + +/** + * Get pointer to lcore variable instance of the current thread. + * + * May only be used by EAL threads and registered non-EAL threads. + */ +#define RTE_LCORE_VAR(handle) \ + RTE_LCORE_VAR_LCORE(rte_lcore_id(), handle) + +/** + * Iterate over each lcore id's value for an lcore variable. + * + * @param lcore_id + * An unsigned int variable successively set to the + * lcore id of every valid lcore id (up to @c RTE_MAX_LCORE). + * @param value + * A pointer variable successively set to point to lcore variable + * value instance of the current lcore id being processed. + * @param handle + * The lcore variable handle. + */ +#define RTE_LCORE_VAR_FOREACH(lcore_id, value, handle) \ + for ((lcore_id) = \ + (((value) = RTE_LCORE_VAR_LCORE(0, handle)), 0); \ + (lcore_id) < RTE_MAX_LCORE; \ + (lcore_id)++, (value) = RTE_LCORE_VAR_LCORE(lcore_id, \ + handle)) + +/** + * Allocate space in the per-lcore id buffers for an lcore variable. + * + * The pointer returned is only an opaque identifier of the variable. To + * get an actual pointer to a particular instance of the variable use + * @ref RTE_LCORE_VAR or @ref RTE_LCORE_VAR_LCORE. + * + * The lcore variable values' memory is set to zero. + * + * The allocation is always successful, barring a fatal exhaustion of + * the per-lcore id buffer space. + * + * rte_lcore_var_alloc() is not multi-thread safe. + * + * The allocated memory cannot be freed. + * + * @param size + * The size (in bytes) of the variable's per-lcore id value. Must be > 0. + * @param align + * If 0, the values will be suitably aligned for any kind of type + * (i.e., alignof(max_align_t)). Otherwise, the values will be aligned + * on a multiple of *align*, which must be a power of 2 and equal or + * less than @c RTE_CACHE_LINE_SIZE. + * @return + * The variable's handle, stored in a void pointer value. The value + * is always non-NULL. + */ +__rte_experimental +void * +rte_lcore_var_alloc(size_t size, size_t align) + __rte_alloc_size(1) __rte_alloc_align(2); + +#ifdef __cplusplus +} +#endif + +#endif /* _RTE_LCORE_VAR_H_ */ diff --git a/lib/eal/linux/eal.c b/lib/eal/linux/eal.c index 54577b7718..d0f27315b9 100644 --- a/lib/eal/linux/eal.c +++ b/lib/eal/linux/eal.c @@ -45,6 +45,7 @@ #include #include "eal_private.h" #include "eal_thread.h" +#include "eal_lcore_var.h" #include "eal_internal_cfg.h" #include "eal_filesystem.h" #include "eal_hugepages.h" @@ -1371,6 +1372,7 @@ rte_eal_cleanup(void) rte_eal_malloc_heap_cleanup(); eal_cleanup_config(internal_conf); rte_eal_log_cleanup(); + eal_lcore_var_cleanup(); return 0; } diff --git a/lib/eal/version.map b/lib/eal/version.map index f493cd1ca7..94dc5b17d6 100644 --- a/lib/eal/version.map +++ b/lib/eal/version.map @@ -399,6 +399,7 @@ EXPERIMENTAL { # added in 24.11 rte_bitset_to_str; + rte_lcore_var_alloc; }; INTERNAL { -- 2.43.0