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 7F7BA45CB7; Fri, 8 Nov 2024 23:34:05 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1F39A4067C; Fri, 8 Nov 2024 23:34:05 +0100 (CET) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id CE77640263 for ; Fri, 8 Nov 2024 23:34:02 +0100 (CET) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 814261DA77 for ; Fri, 8 Nov 2024 23:34:02 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 7501B1DA76; Fri, 8 Nov 2024 23:34:02 +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] (h-62-63-215-114.A163.priv.bahnhof.se [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 55B5B1DB1A; Fri, 8 Nov 2024 23:34:00 +0100 (CET) Message-ID: Date: Fri, 8 Nov 2024 23:34:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] config: limit lcore variable maximum size to 4k To: Thomas Monjalon , David Marchand , =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , =?UTF-8?Q?Morten_Br=C3=B8rup?= Cc: dev@dpdk.org, Bruce Richardson , Stephen Hemminger , Chengwen Feng , Konstantin Ananyev References: <20241108181732.173263-1-david.marchand@redhat.com> <98CBD80474FA8B44BF855DF32C47DC35E9F8B3@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9F8B4@smartserver.smartshare.dk> <27009651.6Emhk5qWAg@thomas> Content-Language: en-US From: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= In-Reply-To: <27009651.6Emhk5qWAg@thomas> 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-11-08 23:13, Thomas Monjalon wrote: > 08/11/2024 20:53, Morten Brørup: >>> From: Morten Brørup [mailto:mb@smartsharesystems.com] >>> Sent: Friday, 8 November 2024 19.35 >>> >>>> From: David Marchand [mailto:david.marchand@redhat.com] >>>> Sent: Friday, 8 November 2024 19.18 >>>> >>>> OVS locks all pages to avoid page faults while processing packets. >> >> It sounds smart, so I just took a look at how it does this. I'm not sure, but it seems like it only locks pages that are actually mapped (current and future). >> >>>> 1M for each lcore translates to allocating 128M with default build >>>> options on x86. >>>> This resulted in OOM while running unit tests in parallel. >> >> Is the root cause the lcore variables library itself, or the unit test using a lot of memory for testing the lcore variables? >> We don't want to fix the library if the problem is elsewhere. > > The fix works for our urgent issue and we want to make a release candidate soon. > > >>>> At the moment, the more demanding DPDK user of lcore variable is >>>> rte_service, with a 2112 bytes object. >>>> >>>> Limit the lcore variable maximum size to 4k which looks more >>>> reasonable. >>> >>> 4 KB is not future proof. >>> >>> Here's an example where 16 KB is cutting it close: >>> https://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35E9F7D0@smart >>> server.smartshare.dk/ >>> >>> Depends on how we are going to use it. 4 KB suffices if we only want to >>> use it for "small" structures. > > This is what is stated in the doc: > "Lcore variables are suitable for small objects" > "The amount of data kept in lcore variables is projected to be small" > >>> Would 64 KB work as a compromise? > > Let's consider based on the need. > The lcore variables are new and we don't want it to degrade the DPDK footprint, > at least not in this first version. > 4 KB is a memory page on common systems, > it looks reasonnable and big enough for a "variable". > > Applied, thanks. > > Why do you have maintainers if you just ignore them?