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 C0FED45B12; Fri, 11 Oct 2024 10:42:27 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 995A84028B; Fri, 11 Oct 2024 10:42:27 +0200 (CEST) Received: from fhigh-a1-smtp.messagingengine.com (fhigh-a1-smtp.messagingengine.com [103.168.172.152]) by mails.dpdk.org (Postfix) with ESMTP id 374B9400D5 for ; Fri, 11 Oct 2024 10:42:26 +0200 (CEST) Received: from phl-compute-05.internal (phl-compute-05.phl.internal [10.202.2.45]) by mailfhigh.phl.internal (Postfix) with ESMTP id B5E5B114015F; Fri, 11 Oct 2024 04:42:25 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Fri, 11 Oct 2024 04:42:25 -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=1728636145; x=1728722545; bh=jqGfCh+goYuj535B9sjik6xoW7k4OVWDRsbbzCN3AzQ=; b= NeNVuYtNp7TEmcRfaZHwa/4UQUVZChDfnTxu6b5HDcLQBAOABRh0nBgVGGUZxY0v B1t5vaSstTyeFC1kt1P4u+zkU32IiKWEReeCkYhILfPaZxydLXV0Ouw+PARDBKD4 Dr9QFjJmmRPy/reT7lbpNyEYYW7EsnjdHeMRNE6EGI2y41yGnM7lDfvFN6iaE1x5 22MzfML7u14I79OCk9v4iPbt3aViwYA7YpCUklTZK/vi6gM8/a5nfS8JTujxUf8x xMHlcQgLxrs1gGvldH9cuuGRQsZ9MnYvePf+9pHkWfWXSBK7J0zb4KiYuyyDPuyX F/mSJTcSjaBqoiEZkt9M/g== 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=1728636145; x= 1728722545; bh=jqGfCh+goYuj535B9sjik6xoW7k4OVWDRsbbzCN3AzQ=; b=k 3wxe0XOF/aETaShe1AtHtTvztLbcU6P8V5ynm/SxQQ1AcOwkDsPAa9E5Qr99MLLU xbPRZzr6w0+dZgR+z6kG7SFB2kcy5hZOm+SyuOPMe/bljQdrl1cyst1Gr2cu6tzR StqhGcWKLA2HfKYKm9AjM2hyCMQ30Wdks4lVXHixzEOclkityiM4kGcp3iWBMCzY HNYGzNMKjdoRm4sXXlt3MPicbmjwB7bEMSAWnZsoLvP4UW4Hrklgr8l5uUqWWhX6 6Z/Qj/3AeBSJngxH9rSFZI+x08qbx6fFvliKpa9REir0k/qlO2ASpupktVcBLL+q curjegYMvYkX4jZrG5//g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvdefkedgtdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhephffvvefufffkjghfggfgtgesthhqredttddtjeen ucfhrhhomhepvfhhohhmrghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrg hlohhnrdhnvghtqeenucggtffrrghtthgvrhhnpefgfeeftdevffffueeiueelhedutefg fefgfeelteehkefgiedvieeugeevfeffueenucffohhmrghinhepsghoohhtlhhinhdrtg homhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpeht hhhomhgrshesmhhonhhjrghlohhnrdhnvghtpdhnsggprhgtphhtthhopeduvddpmhhoug gvpehsmhhtphhouhhtpdhrtghpthhtohepmhgrthhtihgrshdrrhhonhhnsghlohhmsegv rhhitghsshhonhdrtghomhdprhgtphhtthhopehmsgesshhmrghrthhshhgrrhgvshihsh htvghmshdrtghomhdprhgtphhtthhopeguvghvseguphgukhdrohhrghdprhgtphhtthho pehhohhfohhrsheslhihshgrthhorhdrlhhiuhdrshgvpdhrtghpthhtohepshhtvghphh gvnhesnhgvthifohhrkhhplhhumhgsvghrrdhorhhgpdhrtghpthhtohepkhhonhhsthgr nhhtihhnrdhvrdgrnhgrnhihvghvseihrghnuggvgidrrhhupdhrtghpthhtohepuggrvh hiugdrmhgrrhgthhgrnhgusehrvgguhhgrthdrtghomhdprhgtphhtthhopehjvghrihhn jhesmhgrrhhvvghllhdrtghomhdprhgtphhtthhopehluhhkrgdrjhgrnhhkohhvihgtse gvrhhitghsshhonhdrtghomh X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 11 Oct 2024 04:42:23 -0400 (EDT) From: Thomas Monjalon To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= , Morten =?UTF-8?B?QnLDuHJ1cA==?= Cc: dev@dpdk.org, hofors@lysator.liu.se, Stephen Hemminger , Konstantin Ananyev , David Marchand , Jerin Jacob , Luka Jankovic , Mattias =?UTF-8?B?UsO2bm5ibG9t?= , Konstantin Ananyev , Chengwen Feng Subject: Re: [PATCH v9 1/7] eal: add static per-lcore memory allocation facility Date: Fri, 11 Oct 2024 10:42:21 +0200 Message-ID: <12969344.VsHLxoZxqI@thomas> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F7BB@smartserver.smartshare.dk> References: <20241010141349.813088-2-mattias.ronnblom@ericsson.com> <1829355.yIU609i1g2@thomas> <98CBD80474FA8B44BF855DF32C47DC35E9F7BB@smartserver.smartshare.dk> 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 11/10/2024 10:09, Morten Br=C3=B8rup: > > > +static void * > > > +lcore_var_alloc(size_t size, size_t align) > > > +{ > > > + void *handle; > > > + unsigned int lcore_id; > > > + void *value; > > > + > > > + offset =3D RTE_ALIGN_CEIL(offset, align); > > > + > > > + if (offset + size > RTE_MAX_LCORE_VAR) { > > > +#ifdef RTE_EXEC_ENV_WINDOWS > > > + lcore_buffer =3D _aligned_malloc(LCORE_BUFFER_SIZE, > > > + RTE_CACHE_LINE_SIZE); > > > +#else > > > + lcore_buffer =3D aligned_alloc(RTE_CACHE_LINE_SIZE, > > > + LCORE_BUFFER_SIZE); > > > +#endif > > > + RTE_VERIFY(lcore_buffer !=3D NULL); > >=20 > > Please no panic in a lib. > > You can return NULL. >=20 > I agree with Mattias design here. > Lcore variables are like RTE_PER_LCORE variables and simple "static" vari= ables. > If the system does not have enough memory for those, the application will= not be able to deal with it. > Panic early (in this lib) is the correct way to deal with it. There were discussions in the past where we agreed to remove as much panic as possible in our libs and drivers. We want to allow the application to have a chance to cleanup. I don't think returning NULL in an allocation is something disruptive. I understand you don't want to manage an error return in variable declarations, so can we have RTE_VERIFY in declaration macros? > > > + * Lcore variables cannot and need not be freed. > >=20 > > I'm curious about that. > > If EAL is closed, and the application continues its life, > > then we want all this memory to be cleaned as well. > > Do you know rte_eal_cleanup()? >=20 > Good catch, Thomas! I missed that in my review. > Mattias, it seems you need a chained list of lcore_buffer allocations for= this. Yes > > > + * The size of an lcore variable's value must be less than the DPDK > >=20 > > size of variable, not size of value >=20 > Initially, I thought the same as Thomas... > It is confusing considering the handle the variable, and its instances ha= ving values. >=20 > However, during the review, Mattias convinced me of its correctness. >=20 > And by the way, RTE_PER_LCORE also does it: > https://elixir.bootlin.com/dpdk/v24.07/source/lib/eal/include/rte_per_lco= re.h#L48 I understand your point of view and I accept it.