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 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 ; Mon, 14 Oct 2024 17:19:56 +0200 (CEST) Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-20cf6eea3c0so7152445ad.0 for ; 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 To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= Cc: Thomas Monjalon , Mattias =?UTF-8?B?UsO2bm5ibG9t?= , dev@dpdk.org, Morten =?UTF-8?B?QnLDuHJ1?= =?UTF-8?B?cA==?= , Konstantin Ananyev , David Marchand , Jerin Jacob , Luka Jankovic , Konstantin Ananyev , Chengwen Feng 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Mon, 14 Oct 2024 08:51:09 +0200 Mattias R=C3=B6nnblom wrote: > 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 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.