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 EDCE145B50; Wed, 16 Oct 2024 10:10:38 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 32D544021F; Wed, 16 Oct 2024 10:10:38 +0200 (CEST) Received: from fout-b4-smtp.messagingengine.com (fout-b4-smtp.messagingengine.com [202.12.124.147]) by mails.dpdk.org (Postfix) with ESMTP id BA822400D6 for ; Wed, 16 Oct 2024 10:10:36 +0200 (CEST) Received: from phl-compute-06.internal (phl-compute-06.phl.internal [10.202.2.46]) by mailfout.stl.internal (Postfix) with ESMTP id DA2DF11400D6; Wed, 16 Oct 2024 04:10:35 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-06.internal (MEProxy); Wed, 16 Oct 2024 04:10:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1729066235; x=1729152635; bh=Rjqx8bS8a7YSVlhXItIX8zr6FRgXzk7/+AgMUefspe4=; b= CEEYWawWYi1JQxcZTxMd81l+h5Ow2T6ZI+QC40w6t3P2UhDKOL9+nCQhr2p5qTbQ kXy3+W3Tmq7cQ0E/g22tWvahJaoBuUSxbz7TGqSKJH1AiHMexye8FTeP0b1p2yQb s1HxHzzClbOighX/T7CScagCKWyt9qKJhIWYIq7umSvcKyoLzFxAWV/MCUW7etno oSdYcRnmcmZs8uwUzIL8YIWb1KsBNmsd30WMmVj0XIvk6RaSxQLVzpUfto8ZVq+f e8PnTAVERBxABfBaRRaLA5+lZzupxBpwFuxXZgcXtEnE1hp8Cn4HvHNcT7l36KYQ bCo3kzONgIGmwAQtf72+nw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1729066235; x= 1729152635; bh=Rjqx8bS8a7YSVlhXItIX8zr6FRgXzk7/+AgMUefspe4=; b=R 7xO6qi/VQ9q0zkfpdpLSzxi+6CyiGV37uEpqTZH3iel3tmazmolirmc3PZv4bG5F gZLr21tU4Zf8vjoy9oaMmNOX7gK12bcglp0lkIRj/qH+VfVaK8wy+039GoQnFwNR 9wmD2NvDPjQrPYU4bqIVB0ZmSJF8qrdZ4GjYSPLnW85NDJIqn4JrIzM6dZn6Tq6o bPj6QFCQarDMSdvdYEtRL/43oslehHPcMHAKdHeVNJ26ir2C6mdUwkWfYQHLdk4S kiiqaLVIcSifQXfE9gZQgj8NuwscRpSYnm0oMdww/VUc6NOanZCe8c7xTWyce3qd 7S1+7ubQ91a0stEwln9Rw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvdegledgtdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhephffvvefufffkjghfggfgtgesthhqredttddtjeen ucfhrhhomhepvfhhohhmrghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrg hlohhnrdhnvghtqeenucggtffrrghtthgvrhhnpeegtddtleejjeegffekkeektdejvedt heevtdekiedvueeuvdeiuddvleevjeeujeenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtpdhn sggprhgtphhtthhopeduuddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepmhgsse hsmhgrrhhtshhhrghrvghshihsthgvmhhsrdgtohhmpdhrtghpthhtohepmhgrthhtihgr shdrrhhonhhnsghlohhmsegvrhhitghsshhonhdrtghomhdprhgtphhtthhopeguvghvse guphgukhdrohhrghdprhgtphhtthhopehsthgvphhhvghnsehnvghtfihorhhkphhluhhm sggvrhdrohhrghdprhgtphhtthhopehkohhnshhtrghnthhinhdrvhdrrghnrghnhigvvh eshigrnhguvgigrdhruhdprhgtphhtthhopegurghvihgurdhmrghrtghhrghnugesrhgv ughhrghtrdgtohhmpdhrtghpthhtohepjhgvrhhinhhjsehmrghrvhgvlhhlrdgtohhmpd hrtghpthhtoheplhhukhgrrdhjrghnkhhovhhitgesvghrihgtshhsohhnrdgtohhmpdhr tghpthhtohepkhhonhhsthgrnhhtihhnrdgrnhgrnhihvghvsehhuhgrfigvihdrtghomh X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 16 Oct 2024 04:10:33 -0400 (EDT) From: Thomas Monjalon To: Morten =?UTF-8?B?QnLDuHJ1cA==?= , Mattias =?UTF-8?B?UsO2bm5ibG9t?= , dev@dpdk.org Cc: Stephen Hemminger , Konstantin Ananyev , David Marchand , Jerin Jacob , Luka Jankovic , Konstantin Ananyev , Chengwen Feng , Mattias =?UTF-8?B?UsO2bm5ibG9t?= Subject: Re: [PATCH v11 1/7] eal: add static per-lcore memory allocation facility Date: Wed, 16 Oct 2024 10:10:32 +0200 Message-ID: <3337631.l52yBJDM9G@thomas> In-Reply-To: References: <20241011081901.816211-2-mattias.ronnblom@ericsson.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 15/10/2024 09:10, Mattias R=C3=B6nnblom: > On 2024-10-15 08:41, Mattias R=C3=B6nnblom wrote: > > On 2024-10-14 10:17, Morten Br=C3=B8rup wrote: >=20 > >=20 > >> > >>> +/** > >>> + * Get pointer to lcore variable instance with the specified lcore i= d. > >>> + * > >>> + * @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 point= er > >>> + * is also not valid (and thus should not be dereferenced). > >>> + * @param handle > >>> + * The lcore variable handle. > >>> + */ > >>> +#define RTE_LCORE_VAR_LCORE_VALUE(lcore_id, handle) \ > >>> + ((typeof(handle))rte_lcore_var_lcore_ptr(lcore_id, handle)) > >> > >> Please remove the _VALUE suffix. > >> > >=20 > > You changed your mind? I'm missing the rationale here. > >=20 >=20 > I supposed this is a bit of subjective hairsplitting, but does anyone=20 > else have an opinion? >=20 > Short versus somewhat more readable name. >=20 > To get "your own" value should be something like >=20 > struct foo *lcore_foo =3D RTE_LCORE_VAR(foo); > versus > struct foo *lcore_foo =3D RTE_LCORE_VAR_VALUE(foo); >=20 > We should also strip "_VALUE" off of the RTE_LCORE_FOREACH_VALUE() macro= =20 > name in case we change the names of the access macros. I feel "_VALUE" is too much. I prefer the shorter version.