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 63F8D45AFC; Thu, 10 Oct 2024 07:06:50 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DD6644029A; Thu, 10 Oct 2024 07:06:49 +0200 (CEST) Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) by mails.dpdk.org (Postfix) with ESMTP id 81CDC40298 for ; Thu, 10 Oct 2024 07:06:48 +0200 (CEST) Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-20b9b35c7c3so4510335ad.3 for ; Wed, 09 Oct 2024 22:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1728536807; x=1729141607; 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=np/PL9ig4rUOnj49vkHBfaSKqttmm8K/iCn99YwT1Ws=; b=Qv0ChQKy1NP1q1FyQp5cl402xETjelKc12yZEp+HZNnDHyPWu6RwNe++MRfbE/VaqK oe3xgfT82CVyl9AWOJD1xJ0d1OpLULVlWf2NKQGNNYFPNtURrFL0fjjBhO4epvPBHNxp 5O4FD8LhoaH6eilGekBsJ/AzSgbzqwPXhTp5WuBMNtA+XQbmjxXbCq4hGdGJuR6SuhBO Q+kwUhpsP+ZIXiF4ejr1ogRwiWt8SO4HoNBlpN/6ZvL5BFK+5j0/RN2bwgp6lrB3/ldN t85fby5Dpaz3WBnxjGWclGpPa4KjBeY9c+P6n+EvGEHv4Ic6dxw7Rv5Z5wVeb0iyu99R Dxqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728536807; x=1729141607; 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=np/PL9ig4rUOnj49vkHBfaSKqttmm8K/iCn99YwT1Ws=; b=GHhBhqkR0yO0NyB2nXIKk37n4IpTrRHoLkh8xUFo9UvBPjyVyizo3ATHxSKGsHdsKe sf3EIEu3w2vlBFVzvZ7MffK43T8yGyxj2KsRVqLc3MpbRSqN2T4hp2xqIu9jdehkvShC s3lIMY1UXI1XWOLrj9B1HgMI5FwrkuWmFScxES63PhRVMpSS1+1XonaWR38TGF2Ev28o KjWnFaefWQtjFxlqAu/7SPx4e0g/4uFQVV9Irfybw8E3v4mAxnG6rbXnUUecmqggMquA FTXbbHIezGYl4rtCUPLBcH79ibhJAgwffwDJgvBDvwUvFEB6AjmRpXGtIFLYc9u6ya38 qcyQ== X-Gm-Message-State: AOJu0YzswM0SKqh4uW1iZ27+5my9emtEm0wQN3sMtuCJ89WzEf9Vv1sS CBsQivhlX7Qy9Y92224zKauYpZauoYthgEPqgEQtttvDloFPBJ3kXENq2nA4Qyg= X-Google-Smtp-Source: AGHT+IGD2ph52e4WXlIKEbR0qYYmgBHwNPlXWsbz3SxrtrDp1mM/1xBsrFuTZXCj69jc4Hw/DaXlOA== X-Received: by 2002:a17:902:ce88:b0:20b:93be:a2b5 with SMTP id d9443c01a7336-20c63786867mr80684235ad.32.1728536807352; Wed, 09 Oct 2024 22:06:47 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-20c8c213258sm2451735ad.202.2024.10.09.22.06.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Oct 2024 22:06:47 -0700 (PDT) Date: Wed, 9 Oct 2024 22:06:45 -0700 From: Stephen Hemminger To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= Cc: , , Morten =?UTF-8?B?QnLDuHJ1cA==?= , Konstantin Ananyev , David Marchand , Jerin Jacob Subject: Re: [PATCH v7 0/7] Lcore variables Message-ID: <20241009220645.697f06e0@hermes.local> In-Reply-To: <20240918082614.725220-1-mattias.ronnblom@ericsson.com> References: <20240918080054.725164-2-mattias.ronnblom@ericsson.com> <20240918082614.725220-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 Wed, 18 Sep 2024 10:26:07 +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 | 45 +- > doc/guides/rel_notes/release_24_11.rst | 14 + > lib/eal/common/eal_common_lcore_var.c | 79 ++++ > 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 | 390 ++++++++++++++++ > lib/eal/version.map | 2 + > lib/eal/x86/rte_power_intrinsics.c | 17 +- > lib/power/rte_power_pmd_mgmt.c | 35 +- > 17 files changed, 1339 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 Looks good, thanks for taking this on. It will help with scaling for both small systems and mega-core beasts. It would help if you could rebase/resubmit there were some spelling errors and typos that should be fixed before merging. Series-Acked-by: Stephen Hemminger