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 C400B45B13; Fri, 11 Oct 2024 16:25:48 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A86704028B; Fri, 11 Oct 2024 16:25:48 +0200 (CEST) Received: from mail-pg1-f179.google.com (mail-pg1-f179.google.com [209.85.215.179]) by mails.dpdk.org (Postfix) with ESMTP id 37D844025F for ; Fri, 11 Oct 2024 16:25:47 +0200 (CEST) Received: by mail-pg1-f179.google.com with SMTP id 41be03b00d2f7-7db90a28cf6so2294670a12.0 for ; Fri, 11 Oct 2024 07:25:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1728656746; x=1729261546; 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=41wK/8TXRHj/tm4W2N0owueJONXnqkhL5uMuF83Neic=; b=z9aBGwJhn/TrWw7tcKDe/oIEsOjZWFB8TRfeeYji8axnRnCVBKYQhfPwpjtQEAjHEx ET3u8x5sEt4U64au5muuvDxtKMx4bHwvmzFzKLrYgb+xH3WPx5xOK6JQTEya3xBMjDKq XHTduLDNKjwEiszPyCTMP+42qNi4992k3mGca5GqdqpEIV7avDRZB/V4iT2KnPfVH0Fv /DWaKusbAlTiY1kH6b7XCSQVKQgMVRd+h3VpYfEhDBUdDvdfjzTtDtFPhK1juFXYYyzT rWoWqrtVsu+ANl/XGddIEs6zJdtofS/g4bj1NSCrn1Tl/kLkEl8lf6FAFQG3mDBzlg6v Z9aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728656746; x=1729261546; 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=41wK/8TXRHj/tm4W2N0owueJONXnqkhL5uMuF83Neic=; b=vdkl+wBLIAuRmpPtCGPSKmt8cOjtdGGjdluHxDh55BJ0aJQEHDnTR9XBIyzwOX4ZiB mNtLxP/68K9yAEY2HIJwJyJO1FxJqM6honOO1Ddfq5qByw6jKETzaYzw+eRDQjc/RgLV KB4MUcPN+3iR08sod+6YwuT4S7cjHb0cDtJqozCiz6mLZnQHegCIOex4O3ZHKCDVQ0JM yzs8T5WD/d/TxOOlRZY6H0XlO7ohjHMnstELkAU8Y3/H/gijcKDJEQm6mcfYQj3skCnH OZeYdDLTXlYwzN/ek6lKKA7ro9/rZL5DCndNW096az+hPir4NFERYLPW64oNiaVCAsAq ZGhw== X-Gm-Message-State: AOJu0Yy9d9cXB7zeskj+uF7CLC0hGtnBaH+PXNLXZ3YRcQNnWMGuxyeN QQGRSuLnW1n4XQaR102szpmz4HUnXnpMaBYRvbn7VvEm+59QDypWnaua9jC3uRE= X-Google-Smtp-Source: AGHT+IH/pKkM/rJbP8C0N/Yl1G71poYiXBnpxIv+HNGkk6mscPA8SIddtVwsRw3FvI4lJYDgWo1MyA== X-Received: by 2002:a17:90a:c2c6:b0:2e2:a5fd:7e4c with SMTP id 98e67ed59e1d1-2e2f0aa8b36mr4625119a91.8.1728656746303; Fri, 11 Oct 2024 07:25:46 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2e2d5dd2b65sm3238934a91.2.2024.10.11.07.25.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Oct 2024 07:25:46 -0700 (PDT) Date: Fri, 11 Oct 2024 07:25:44 -0700 From: Stephen Hemminger To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= Cc: , , Morten =?UTF-8?B?QnLDuHJ1cA==?= , Konstantin Ananyev , David Marchand , Jerin Jacob , Luka Jankovic Subject: Re: [PATCH v10 0/7] Lcore variables Message-ID: <20241011072544.47a041c1@hermes.local> In-Reply-To: <20241011081901.816211-1-mattias.ronnblom@ericsson.com> References: <20241010142205.813134-2-mattias.ronnblom@ericsson.com> <20241011081901.816211-1-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 Fri, 11 Oct 2024 10:18:54 +0200 Mattias R=C3=B6nnblom wrote: > This patch set introduces a new API for static > per-lcore id data allocation. >=20 > Please refer to the API documentation for both a > rationale for this new API, and a comparison to the alternatives > available. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Mattias R=C3=B6nnblom (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 >=20 > 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 >=20 Are there any trace points in this code? Would be good to have. Also some optional statistics for telemetry use. I would presume this is not intended as a hot path API; therefore it would be ok to always keep statistics.