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 3D18F45CE3; Mon, 11 Nov 2024 07:31:48 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2802A40E27; Mon, 11 Nov 2024 07:31:48 +0100 (CET) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id BBB044067A for ; Mon, 11 Nov 2024 07:31:46 +0100 (CET) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 09DF16377 for ; Mon, 11 Nov 2024 07:31:45 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id E19BF63EB; Mon, 11 Nov 2024 07:31:45 +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 E3249645C; Mon, 11 Nov 2024 07:31:41 +0100 (CET) Message-ID: Date: Mon, 11 Nov 2024 07:31:41 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] config: limit lcore variable maximum size to 4k To: Thomas Monjalon Cc: David Marchand , =?UTF-8?Q?Morten_Br=C3=B8rup?= , dev@dpdk.org, Bruce Richardson , Stephen Hemminger , Chengwen Feng , Konstantin Ananyev References: <20241108181732.173263-1-david.marchand@redhat.com> <27009651.6Emhk5qWAg@thomas> <6948023.R56niFO833@thomas> Content-Language: en-US From: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= In-Reply-To: <6948023.R56niFO833@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-09 00:11, Thomas Monjalon wrote: > 08/11/2024 23:34, Mattias Rönnblom: >> 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? > > I didn't receive your replies when I started to write this. > Please be comprehensive. > We are in a hurry to stabilize this before the release candidate which is already late. > > I'll change to 128 KB as you recommend before pushing to the repository. > Thanks. > PS: maybe I should not have merged this feature in 24.11. > Ideally, it should have been merged earlier in the release cycle. I did offer the documentation you asked for as a separate patch, to be delivered later.