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 C31FE45CB7; Sat, 9 Nov 2024 00:11:20 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AF40C40268; Sat, 9 Nov 2024 00:11:20 +0100 (CET) Received: from fout-a3-smtp.messagingengine.com (fout-a3-smtp.messagingengine.com [103.168.172.146]) by mails.dpdk.org (Postfix) with ESMTP id 0D50D40263 for ; Sat, 9 Nov 2024 00:11:19 +0100 (CET) Received: from phl-compute-04.internal (phl-compute-04.phl.internal [10.202.2.44]) by mailfout.phl.internal (Postfix) with ESMTP id 7DD151380212; Fri, 8 Nov 2024 18:11:18 -0500 (EST) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-04.internal (MEProxy); Fri, 08 Nov 2024 18:11:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1731107478; x=1731193878; bh=H9IUCT7YgQT6FAXzQPRpcakweJ2hzusCI9Fge3p2OOQ=; b= Zbq9kR3/G7jD9M9McNxBMQgzAoCgnfHBYuQZ5WtV+lU9pgdBRmyMV6f8JVF25r0J fB53y1OxoJkChJoVk7bTvueuqRAsxcUGV2JRFNnFRyIV/9ibUUmVbQi/BMkj3RON mW3nQrFuZGWDwX7a8Q8zXrbmTREqVgno7/IfJIEMi6dF1b2Q/rMaBXrm88grFffN zk3ESnfWI2/kn/+GrxafKC4ojGmVxosnlaLICu2yRfPutfQt00xOd/XZ8t4BZIZO 2dMBmMvUwm3ZB+fMudIEgPQf0w70hVo7TL+XUiwVlNIZxZZkNhdvaNG4iFhUWUyK cWaMiC/vF65+EW+zbgXMrA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1731107478; x= 1731193878; bh=H9IUCT7YgQT6FAXzQPRpcakweJ2hzusCI9Fge3p2OOQ=; b=j QcnNERVfKNOn+nL+ZnhcRldgIaF33Vqc92+hWSVKkA0Fn5Ll7ukIbtUwHRgpq3sT B0LlZUZjwvSU9ZpuiZronY2JDgK5iTjO23fVR27oMScvcDfaG1OjzQxJky1GHzSf jP71kfJCx/dOQkYdTkdp0bDXe4JuktdksiO9tE7Jrvp6AY/Ju+ROQJzqFCnGfh/G t73mc2pGHgPHBJeRrGeRJQcLVURXeDU1+YGsRBTXqbLN6OVkpagYTXo6D32dg1S1 FWpkygcVS5rIk6UM3UOnzeeXTmq2W622+9/+gcs1AvrX3W5cULGwTk/4aKwMjHKh 32lkE8/aVbHy2tp7Z8PGQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrtdejgddtjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth hsucdlqddutddtmdenucfjughrpefhvfevufffkfgjfhgggfgtsehtqhertddttdejnecu hfhrohhmpefvhhhomhgrshcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlh honhdrnhgvtheqnecuggftrfgrthhtvghrnhephefggfeftdffveffffeuhfffffegvdeu hedtkeefkeevudekgfevueefffelvdeknecuffhomhgrihhnpeguphgukhdrohhrghdpsh hmrghrthhshhgrrhgvrdgukhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhep mhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtpdhnsggprhgtph htthhopeekpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehhohhfohhrsheslhih shgrthhorhdrlhhiuhdrshgvpdhrtghpthhtohepuggrvhhiugdrmhgrrhgthhgrnhguse hrvgguhhgrthdrtghomhdprhgtphhtthhopehmsgesshhmrghrthhshhgrrhgvshihshht vghmshdrtghomhdprhgtphhtthhopeguvghvseguphgukhdrohhrghdprhgtphhtthhope gsrhhutggvrdhrihgthhgrrhgushhonhesihhnthgvlhdrtghomhdprhgtphhtthhopehs thgvphhhvghnsehnvghtfihorhhkphhluhhmsggvrhdrohhrghdprhgtphhtthhopehfvg hnghgthhgvnhhgfigvnheshhhurgifvghirdgtohhmpdhrtghpthhtohepkhhonhhsthgr nhhtihhnrdgrnhgrnhihvghvsehhuhgrfigvihdrtghomh X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 8 Nov 2024 18:11:16 -0500 (EST) From: Thomas Monjalon To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= Cc: David Marchand , Morten =?UTF-8?B?QnLDuHJ1cA==?= , dev@dpdk.org, Bruce Richardson , Stephen Hemminger , Chengwen Feng , Konstantin Ananyev Subject: Re: [PATCH] config: limit lcore variable maximum size to 4k Date: Sat, 09 Nov 2024 00:11:14 +0100 Message-ID: <6948023.R56niFO833@thomas> In-Reply-To: References: <20241108181732.173263-1-david.marchand@redhat.com> <27009651.6Emhk5qWAg@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 08/11/2024 23:34, Mattias R=C3=B6nnblom: > On 2024-11-08 23:13, Thomas Monjalon wrote: > > 08/11/2024 20:53, Morten Br=C3=B8rup: > >>> From: Morten Br=C3=B8rup [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 su= re, 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. > >=20 > > The fix works for our urgent issue and we want to make a release candid= ate soon. > >=20 > >=20 > >>>> 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@sma= rt > >>> 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. > >=20 > > 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? > >=20 > > Let's consider based on the need. > > The lcore variables are new and we don't want it to degrade the DPDK fo= otprint, > > 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". > >=20 > > Applied, thanks. >=20 > 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 a= lready late. I'll change to 128 KB as you recommend before pushing to the repository. PS: maybe I should not have merged this feature in 24.11.