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 C82ED45B50; Wed, 16 Oct 2024 10:05:30 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 98E6D4021F; Wed, 16 Oct 2024 10:05:30 +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 048F3400D6 for ; Wed, 16 Oct 2024 10:05:29 +0200 (CEST) Received: from phl-compute-03.internal (phl-compute-03.phl.internal [10.202.2.43]) by mailfout.stl.internal (Postfix) with ESMTP id D996F11400AA; Wed, 16 Oct 2024 04:05:27 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-03.internal (MEProxy); Wed, 16 Oct 2024 04:05:28 -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=1729065927; x=1729152327; bh=fv+VK+Bn2dlWr7KRfh3mvSTLmuBsIv9F5+8PEhvZUcQ=; b= HpiNDOqPBFHIK2SQ4kkD0ZOjF48gqxYxwLMGj9CeLqJBXs5jnXrswCebVphsud5a 9WSG+N0shrvYgy0maAQj6JEtaD3vwEPurb4kEMC2VvjCsBbYtF/jHgYHs4f0LFT4 TAcSiYo1NkE7lNk6h1nhFF86L7b9LBtDpZWrCG/KBRyPvIhod32mrzp4GlvmH4sM vGoiY9cylEWFLXiL86jrIu5zWVWy5k/FI/0SeprMrYLcwg03u1R63iO/81FNyOxa Dv2AbrIUjp4v4cpspLQaSXLoHvvsh/r90MkA+EwhNpjEE65qi9J5+096NbJ7xj+N j8CKt3le+waSSphAjWWstw== 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=1729065927; x= 1729152327; bh=fv+VK+Bn2dlWr7KRfh3mvSTLmuBsIv9F5+8PEhvZUcQ=; b=d Swm20BNfYCm5oDPi1x0SJJKXxqIbZgh+AlqOdGHPvCk46oQe1TIPh6f9px4OOXGx hQFZfGs6KL4nXGkuDjSxjdD1apeTOkI5UbXQHOR2Q/d80ho2BarJ4oZqpW8HOwA9 fxMGfxMQAXez8D4qy4kfyJh53kJU8gS5c8jBLZ6mNw6uu/A5crYdFv4j71nIf3aU tnTdAUXhI90MoRz0jiKWP3XSQrTjbz5GO/3LJnOgJaVazOYy8cUFaam7oYsgc8vf b/YWinzoSFlQHbAZM8RS+uO1u+zT9VSLcHduJ3QMXVdQlO3J1CHxJow9P95h200s +vCMH78xPIqmTco/orgmQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvdegkedguddvkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpefhvfevufffkfgjfhgggfgtsehtqhertddttdej necuhfhrohhmpefvhhhomhgrshcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjh grlhhonhdrnhgvtheqnecuggftrfgrthhtvghrnhepgedttdeljeejgeffkeekkedtjeev tdehvedtkeeivdeuuedvieduvdelveejueejnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvthdp nhgspghrtghpthhtohepuddupdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehhoh hfohhrsheslhihshgrthhorhdrlhhiuhdrshgvpdhrtghpthhtohepmhgssehsmhgrrhht shhhrghrvghshihsthgvmhhsrdgtohhmpdhrtghpthhtohepuggvvhesughpughkrdhorh hgpdhrtghpthhtohepmhgrthhtihgrshdrrhhonhhnsghlohhmsegvrhhitghsshhonhdr tghomhdprhgtphhtthhopehkohhnshhtrghnthhinhdrvhdrrghnrghnhigvvheshigrnh guvgigrdhruhdprhgtphhtthhopegurghvihgurdhmrghrtghhrghnugesrhgvughhrght rdgtohhmpdhrtghpthhtohepjhgvrhhinhhjsehmrghrvhgvlhhlrdgtohhmpdhrtghpth htoheplhhukhgrrdhjrghnkhhovhhitgesvghrihgtshhsohhnrdgtohhmpdhrtghpthht ohepkhhonhhsthgrnhhtihhnrdgrnhgrnhihvghvsehhuhgrfigvihdrtghomh X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 16 Oct 2024 04:05:25 -0400 (EDT) From: Thomas Monjalon To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= , Morten =?UTF-8?B?QnLDuHJ1cA==?= Cc: dev@dpdk.org, Mattias =?UTF-8?B?UsO2bm5ibG9t?= , Konstantin Ananyev , David Marchand , Jerin Jacob , Luka Jankovic , Konstantin Ananyev , Chengwen Feng , Stephen Hemminger Subject: Re: [PATCH v9 1/7] eal: add static per-lcore memory allocation facility Date: Wed, 16 Oct 2024 10:05:23 +0200 Message-ID: <2431186.bcXerOTE6V@thomas> In-Reply-To: <20241014081953.7d931bbe@hermes.local> References: <20241010141349.813088-2-mattias.ronnblom@ericsson.com> <99c08d4b-d8bc-48d2-92f2-1ce37e61eff6@lysator.liu.se> <20241014081953.7d931bbe@hermes.local> 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 14/10/2024 17:19, Stephen Hemminger: > On Mon, 14 Oct 2024 08:51:09 +0200 > Mattias R=C3=B6nnblom wrote: >=20 > > On 2024-10-11 10:04, Mattias R=C3=B6nnblom wrote: > > > On 2024-10-10 23:24, Thomas Monjalon wrote: =20 > >=20 > > > >=20 > > >>> + * > > >>> + * An lcore variable is not tied to the owning thread's lifetime. = It's > > >>> + * available for use by any thread immediately after having been > > >>> + * allocated, and continues to be available throughout the lifetim= e of > > >>> + * the EAL. > > >>> + * > > >>> + * 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 > > >=20 > > > I think the primary reason you would like to free the buffers is to=20 > > > avoid false positives from tools like valgrind memcheck (if anyone=20 > > > managed to get that working with DPDK). > > >=20 > > > rte_eal_cleanup() freeing the buffers and resetting the offset would= =20 > > > make sense. That however would require the buffers to be tracked (e.g= =2E,=20 > > > as a linked list). > > > =20 > >=20 > > I had a quick look at this. Cleaning up the lcore var buffers is very=20 > > straightforward. > >=20 > > One thing though: the rte_eal_cleanup() documentation says "After this= =20 > > call, no DPDK function calls may be made.". rte_eal_init() is a "DPDK=20 > > function call". So DPDK/EAL can never be re-initialized, correct? >=20 > In practice, calling rte_eal_init() is not tested, and some of the drivers > probably won't work. Yes it is not tested, I have no idea whether restarting DPDK works or not.