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 B903E45EDF; Wed, 18 Dec 2024 21:11:02 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4CB8540EE2; Wed, 18 Dec 2024 21:11:02 +0100 (CET) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id 5DB1240DF5 for ; Wed, 18 Dec 2024 21:11:01 +0100 (CET) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id E7E23D04A for ; Wed, 18 Dec 2024 21:11:00 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 7E6BDD049; Wed, 18 Dec 2024 21:11:00 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=ALL_TRUSTED,AWL, T_SCC_BODY_TEXT_LINE autolearn=disabled version=4.0.0 X-Spam-Score: -1.2 Received: from [192.168.1.85] (unknown [62.63.215.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id CA8ADCFDD; Wed, 18 Dec 2024 21:10:57 +0100 (CET) Message-ID: <10f9eb7d-da14-4a75-b004-e7b2673500d2@lysator.liu.se> Date: Wed, 18 Dec 2024 21:10:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/3] Defer lcore variables allocation To: David Marchand , "Burakov, Anatoly" Cc: dev@dpdk.org, thomas@monjalon.net, frode.nordahl@canonical.com, mattias.ronnblom@ericsson.com References: <20241205175754.1673888-1-david.marchand@redhat.com> Content-Language: en-US From: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP 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 2024-12-16 10:49, David Marchand wrote: > On Mon, Dec 16, 2024 at 10:42 AM Burakov, Anatoly > wrote: >> >> On 12/5/2024 6:57 PM, David Marchand wrote: >>> As I had reported in rc2, the lcore variables allocation have a >>> noticeable impact on applications consuming DPDK, even when such >>> applications does not use DPDK, or use features associated to >>> some lcore variables. >>> >>> While the amount has been reduced in a rush before rc2, >>> there are still cases when the increased memory footprint is noticed >>> like in scaling tests. >>> See https://bugs.launchpad.net/ubuntu/+source/dpdk/+bug/2090931 >>> >>> >>> lcore variable allocations in constructor is a bad idea, as the >>> application consuming DPDK has no control over such allocation: >>> linking some code does not mean that all of it will be used at runtime. >>> >>> The general question on whether lcore variables in constructor should >>> be forbidden, is left to a later discussion. >>> >>> For now, this series only focus on fixing subsystems using lcore >>> variables so that those allocations are deferred either in rte_eal_init() >>> or in the path that does require such lcore variables. >>> >>> >> >> An idle question: would this have any consequences in use case of eal >> init -> eal cleanup -> eal init with different arguments? > > Hum, interesting question. > > I would say that initialising lcore variables in constructors means > that this usecase is broken, since lcore variables are freed in > eal_lcore_var_cleanup(). > > After rte_eal_cleanup() is called, no DPDK calls may be made. So, with the current API, there is no such use case to break.