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 53D9B45B13; Fri, 11 Oct 2024 16:23:31 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 10751402A1; Fri, 11 Oct 2024 16:23:31 +0200 (CEST) Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com [209.85.210.169]) by mails.dpdk.org (Postfix) with ESMTP id B9D0C4028B for ; Fri, 11 Oct 2024 16:23:29 +0200 (CEST) Received: by mail-pf1-f169.google.com with SMTP id d2e1a72fcca58-71df67c6881so1822274b3a.3 for ; Fri, 11 Oct 2024 07:23:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1728656609; x=1729261409; 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=IxddQRFu7hZs8D9KqjXjtU2reVj5achgqWESDnVJBJM=; b=TWxRtjiN1MgB5pJsQwrnkdFpOht1YmvHEH5CifrCaAnD/ZBqWvrlyPoXHmZh9uESWE VK4NPkZDFo33Jf86lrBI33D4OAr3DkkJXDDMH//bu2qVP5MOKs2ZxIVo8gnVHzlBO5Qw WHiFCDFZviD+4CyqhltJlo9W6DQMJxmZkJ2n70+Jejcd+InmuCO0NWoB6M0CSvUte9lv 3AVUVMnMZ5bMGcu05PyFaBYfhqFzFOGE0CmkZ82kRXEOBSeq7+w239Ahsm7s7vfJmP3R 51sATh4UF7RE8luicSlIluFv1YlEwxS1SSdX8Ir7X3lRUB22Hy3+prjpJn6WlWZZHByC s/5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728656609; x=1729261409; 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=IxddQRFu7hZs8D9KqjXjtU2reVj5achgqWESDnVJBJM=; b=haLL7M7wI9YdYBwIub/EScNAugcmvuQ749YXRZxqoKhraqdsEXEz0tNEeAkQHP2CBG gI4G7VYyHXvc8vLhIVFQ6O7T2HQklBdmjy87N8IBZxaTci3X4At+B66SqwTRQCtVLXhw 6Wg9VTRMqSudCfEguzCUqjHvWHAaQ30PUQUUL3Cffkb6BS9Y6icXcNxVKDgkJQVFys8c m1lWBlZY3luIsUyeERFSWLiKQamIMexk/jNbthCgtVWsxL4l7sLqNF1bwBdgQjIVTeRc 7zJ2kdelB/kEdHSWMh6SsxKODk7+UXYqs2MQPa+glmdR+XQb0Jk3Vbgeg8TQRleuKj8e 23IA== X-Gm-Message-State: AOJu0Yzi5magEhwK2Z+CkN1JnuYykZ2H7ZoGe6nn0tVgENbkEmVQXYCY 3A8XMauxXUgLRxM9CwpzKRyBfPsVTfMzJFgVrETGFEw8iMOGYt0Ysvf7wrgztRg= X-Google-Smtp-Source: AGHT+IGGl7F8ywedQqtKWD3hboRS+tBkdgomJqufLJ5iybTVK58KXYuJ00OSNV5PTvvVDpVMjPUhmg== X-Received: by 2002:a05:6a00:21d2:b0:71e:6b8:2f4a with SMTP id d2e1a72fcca58-71e37e4fedemr5690819b3a.12.1728656608757; Fri, 11 Oct 2024 07:23:28 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-71e2ab0fcf4sm2621781b3a.219.2024.10.11.07.23.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Oct 2024 07:23:28 -0700 (PDT) Date: Fri, 11 Oct 2024 07:23:26 -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 v8 0/7] Lcore variables Message-ID: <20241011072326.4a2ec420@hermes.local> In-Reply-To: <20241010141349.813088-1-mattias.ronnblom@ericsson.com> References: <20240918082614.725220-2-mattias.ronnblom@ericsson.com> <20241010141349.813088-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 Thu, 10 Oct 2024 16:13:42 +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. There should be a mention about whether this storage can be shared with other threads and processes. Is it like huge page memory or stack or heap?