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 A83D545B51; Wed, 16 Oct 2024 16:58:15 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3546040150; Wed, 16 Oct 2024 16:58:15 +0200 (CEST) Received: from mail-pf1-f171.google.com (mail-pf1-f171.google.com [209.85.210.171]) by mails.dpdk.org (Postfix) with ESMTP id 4597D400D6 for ; Wed, 16 Oct 2024 16:58:13 +0200 (CEST) Received: by mail-pf1-f171.google.com with SMTP id d2e1a72fcca58-71e681bc315so785334b3a.0 for ; Wed, 16 Oct 2024 07:58:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1729090692; x=1729695492; 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=32mb9dX3Q3q/Ax1Dv9yvPBzfbeRhtsBS6UcwZlPBC3w=; b=LenwHuh+YErK1NsD91xZhBAgqrbzdXiO40t9MFOUUzsh0fEhIcAux6vEtHGV+xGQil Jxw2gyg1X4PBcuR5DBjlgXq8hPBydgm0zoCFoWKU58lHyx4terLFC/wB1r4yIeN/os3f xwka1GfC3J+yZIaUE5eROQwVXjKqhyeIBHdbeE7IVZfoTbFBovrDSXUkTm6hRcW8l2SL 6TxQUF+yhPaAZL9UR3NVqJNUB8sWXYShOPtYXnECHEprqx9AEe8rvuP11nK63cw4sa6o VFG/ul8H6gV/DSY3H9BoHp/jHk3Ex0kB/hh6ijiyvN8rJnfx8NGGzpuXhPrei6De+Len HHNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729090692; x=1729695492; 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=32mb9dX3Q3q/Ax1Dv9yvPBzfbeRhtsBS6UcwZlPBC3w=; b=r8LJHAN0PJWFSBaeXRv/Tv3UIklF8zlK1h01+6+AMtC31xdI3E1xsJEp9eVK5QzC2Q sAgjM/6RQVqdXUlB/AHKEH7gVLqSt/eg6mnePIX3S2Nj6edQ2BtnXBF3WyoLzNraX91r YPH7cbzBKOL6eEjhiR9TWcImasMka+wS2ZCm+Fq5Qwdr+8i1a7LTZuSLrhQFXKZ2+kpM +wkZb/ZugfvYbJSoZFk+XfF+H7W64ojtZsyGs/IhCEXa75b5WN0EjnUV1z+8lt55jlHw PhkxKPdYdwjDQIPh5L+GpTPEDisH3D0ITs6TJ5Vg+WMiLvOld/Csh+j7GT4XqiZ9qtnk Bawg== X-Gm-Message-State: AOJu0YztXh02nWuAxQfMN7zDbPbHt9Lw8QhZ5gUs98Y9xiqyZzZMXDcY gTpqTsBbmsTzZCPMOjOe9x0UzBZq0NxDmagX0AEI2Mif+sth/+im8lfGfqhxmWs= X-Google-Smtp-Source: AGHT+IGCtj+WuHMM7ExxsQpHe/ug9T/KYFX6dnOnlFcOuai+22b8rq9ysSoO5UHLiLpzCdQ5pR4eGw== X-Received: by 2002:a05:6a00:21cf:b0:71e:6a99:4732 with SMTP id d2e1a72fcca58-71e6a9948e6mr15375117b3a.11.1729090692196; Wed, 16 Oct 2024 07:58:12 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-71e77518ad1sm3140160b3a.215.2024.10.16.07.58.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Oct 2024 07:58:12 -0700 (PDT) Date: Wed, 16 Oct 2024 07:58:10 -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 v14 0/7] Lcore variables Message-ID: <20241016075810.7f953ea7@hermes.local> In-Reply-To: <20241016131916.827788-1-mattias.ronnblom@ericsson.com> References: <20241015093344.824073-2-mattias.ronnblom@ericsson.com> <20241016131916.827788-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, 16 Oct 2024 15:19:09 +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 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 Still too wordy, would you mind if I have a try and summarizing and=20 running the text through an editor tool?