From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 495F245B38;
	Mon, 14 Oct 2024 17:19:58 +0200 (CEST)
Received: from mails.dpdk.org (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id D44114027F;
	Mon, 14 Oct 2024 17:19:57 +0200 (CEST)
Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com
 [209.85.214.181])
 by mails.dpdk.org (Postfix) with ESMTP id B247640151
 for <dev@dpdk.org>; Mon, 14 Oct 2024 17:19:56 +0200 (CEST)
Received: by mail-pl1-f181.google.com with SMTP id
 d9443c01a7336-20cf6eea3c0so7152445ad.0
 for <dev@dpdk.org>; Mon, 14 Oct 2024 08:19:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1728919196;
 x=1729523996; 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=vpGdHOiRihaPbfcwW8qLyMXptNqwSTCp91Q1k5YfTno=;
 b=YXg71W3mUsTNyarO4ZOBKik4LoctY6kSHeMcpzziavU6QJwjq98fJagz5UEOxuJQ7T
 jnLC/X6exoeGe0eRpAfdnIZBHxz1YHO6U79Smnjy2pQwTFwUsHwSEiFUix+9Cikdz8LL
 MTglaSPucipX5QDowbbwxCCbvHHLVu+b/y79wwMLNCpmFeRk7uM5lmEQAVYdbCMxVnUu
 QYOC0Fld9U5ump1arm7ZdOz13jFevbzOhaYtlnl7civjyPybO7acHTdfkr+qw/O1gmpF
 1RmeAjA8o9XIa534fAQme+rCdPRHh6CeKuz/ERlqWtNYV8Nx6ob6tNIvXIRDn0F2JkJC
 1srg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1728919196; x=1729523996;
 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=vpGdHOiRihaPbfcwW8qLyMXptNqwSTCp91Q1k5YfTno=;
 b=qsBSlsoj0S4TtxSMG9J+rpdPb84lzheKh8U43q2s9VCIL+Q8kSRR5cwV2ihifFrVpI
 rLFMlyHAA4r2Vq9fHba8/diToyPsRCtWPzM8xPr670kPilZgs21l4DWe2RUDn5Cbe/py
 y8v6hU/7hQes3JzCrlJ1QFKC1+bx8EP7cQZg2RWYoFUB7U6bEE3B75UR26CHk9zTnOhf
 8/4uZVm8dHsYqM+fivzOO8J43CzJ8YLqIAC9LGLDydKLaHqhJqolY+BAqp60ihA8n7p8
 IIXf5Nn15PgmmtYeguMYxmZ2GafU4hWJ00Z2aKNh6yUxLWHtu9zs3afuZlL8KapNEKX4
 n0hQ==
X-Forwarded-Encrypted: i=1;
 AJvYcCWOi00YuCmSDtlLddD2GPI0MQcE4hhUTuYb1uo3IM5nbwqHVX8PWreQSeGWe4OJSzCoW00=@dpdk.org
X-Gm-Message-State: AOJu0YznqZMgS1ohchN7VMk/trvXBaAB46B3RhoihUA9Cswc+tPuCnDk
 htP7ygxngd5y6AyGPLgDiZVLxyvyIr9SGS3rvuyvkkJOqCSUc8jMtWkB3E/vLNI=
X-Google-Smtp-Source: AGHT+IFEih5Mzx1iS/a/NRpWtaH2nj0dCKGSrNR7y5DR4+h4VVesWPhD3VjcC6vblgUk0A9dymRh5A==
X-Received: by 2002:a17:902:e802:b0:20c:9821:6998 with SMTP id
 d9443c01a7336-20ca142459dmr153792065ad.10.1728919195693; 
 Mon, 14 Oct 2024 08:19:55 -0700 (PDT)
Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-20c8c0e74c0sm67501935ad.121.2024.10.14.08.19.55
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 14 Oct 2024 08:19:55 -0700 (PDT)
Date: Mon, 14 Oct 2024 08:19:53 -0700
From: Stephen Hemminger <stephen@networkplumber.org>
To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= <hofors@lysator.liu.se>
Cc: Thomas Monjalon <thomas@monjalon.net>, Mattias =?UTF-8?B?UsO2bm5ibG9t?=
 <mattias.ronnblom@ericsson.com>, dev@dpdk.org, Morten =?UTF-8?B?QnLDuHJ1?=
 =?UTF-8?B?cA==?= <mb@smartsharesystems.com>, Konstantin Ananyev
 <konstantin.v.ananyev@yandex.ru>, David Marchand
 <david.marchand@redhat.com>, Jerin Jacob <jerinj@marvell.com>, Luka
 Jankovic <luka.jankovic@ericsson.com>, Konstantin Ananyev
 <konstantin.ananyev@huawei.com>, Chengwen Feng <fengchengwen@huawei.com>
Subject: Re: [PATCH v9 1/7] eal: add static per-lcore memory allocation
 facility
Message-ID: <20241014081953.7d931bbe@hermes.local>
In-Reply-To: <99c08d4b-d8bc-48d2-92f2-1ce37e61eff6@lysator.liu.se>
References: <20241010141349.813088-2-mattias.ronnblom@ericsson.com>
 <20241010142205.813134-1-mattias.ronnblom@ericsson.com>
 <20241010142205.813134-2-mattias.ronnblom@ericsson.com>
 <1829355.yIU609i1g2@thomas>
 <5818e22a-1e22-4533-85b8-fb9d00c834da@lysator.liu.se>
 <99c08d4b-d8bc-48d2-92f2-1ce37e61eff6@lysator.liu.se>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org

On Mon, 14 Oct 2024 08:51:09 +0200
Mattias R=C3=B6nnblom <hofors@lysator.liu.se> wrote:

> On 2024-10-11 10:04, Mattias R=C3=B6nnblom wrote:
> > On 2024-10-10 23:24, Thomas Monjalon wrote: =20
>=20
> <snip>
>=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 lifetime =
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.,=
=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?

In practice, calling rte_eal_init() is not tested, and some of the drivers
probably won't work.