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 8CED545CB7; Fri, 8 Nov 2024 23:13:08 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 21AE74067C; Fri, 8 Nov 2024 23:13:08 +0100 (CET) Received: from fhigh-a6-smtp.messagingengine.com (fhigh-a6-smtp.messagingengine.com [103.168.172.157]) by mails.dpdk.org (Postfix) with ESMTP id B684740263 for ; Fri, 8 Nov 2024 23:13:06 +0100 (CET) Received: from phl-compute-02.internal (phl-compute-02.phl.internal [10.202.2.42]) by mailfhigh.phl.internal (Postfix) with ESMTP id 35DFC114010B; Fri, 8 Nov 2024 17:13:06 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Fri, 08 Nov 2024 17:13:06 -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=1731103986; x=1731190386; bh=vaUhia0gc48t890zb1A5f0UX0KOuWIPxniRlUyoPeHc=; b= WSe07jcYlpzL7scEPdUiSS6GFErOobMR+ql6IXdhAUyp4aOqRUrwpsyl0gANTeHh dLD3Zs9Epf3CP0MKNPk+fYgbIbcG0e8F34PjComEbB4ax5DGnT1Pp9E51JfUG0B+ 3CKoGwhX6sdywu2mZBoVcdYsgonr7d5LBy4DizrlUCuldssurgNJx1KtETO/SiS8 6Ic2CbvLXgJYqBe0BAAePGRvsmr2GCemE6b23H9SCt4fFVVANcrsEW8DBfjwsKJU s74xpTu1U1rDID7WxjDXBhJqoHsHsAv4DmKmXinl7hn6udt/e3deNQxVwFAMQc0W W4efbDvkZ3jCF9lZ70nP2w== 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=1731103986; x= 1731190386; bh=vaUhia0gc48t890zb1A5f0UX0KOuWIPxniRlUyoPeHc=; b=Y AdluZC+VB/4ycJlJ/PX475M12gqZMwEXOz2KO3vyHTdc3Y3ZXNuHQL4wNLuBmPxH ClGuEzj42I6+jeUxmPxusy6T7gDrZ9IDaMWe4l42Qf8ZIBCDdz8mhtuLZ13MvF6p 2++zuNUlDGOdlw28POAIILzOHHOa1ktORunIn4s2LlWCFUFgsYuZ1Jsw5Y9RhV0J HwbiJ50gkXHKV7BGIVJey4S9huAUsDnwsp0/Poukkf4z8JDrUumZagSXNjTHjeV3 R1ZEtOxjOAUwPbAXQCsq+h43MvN5Vy2/Lc1ov8VqYoZ/AoLZy409zyrgJprjkUV3 1nPyA9SNNhGJ/XEUI1rLQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrtdeigdduheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhephffvvefufffkjghfggfgtgesthhqredttddtjeen ucfhrhhomhepvfhhohhmrghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrg hlohhnrdhnvghtqeenucggtffrrghtthgvrhhnpeehgffgfedtffevffffuefhffffgedv ueehtdekfeekvedukefgveeufeffledvkeenucffohhmrghinhepughpughkrdhorhhgpd hsmhgrrhhtshhhrghrvgdrughknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghm pehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvthdpnhgspghrtg hpthhtohepkedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepuggrvhhiugdrmhgr rhgthhgrnhgusehrvgguhhgrthdrtghomhdprhgtphhtthhopehmrghtthhirghsrdhroh hnnhgslhhomhesvghrihgtshhsohhnrdgtohhmpdhrtghpthhtohepmhgssehsmhgrrhht shhhrghrvghshihsthgvmhhsrdgtohhmpdhrtghpthhtohepuggvvhesughpughkrdhorh hgpdhrtghpthhtohepsghruhgtvgdrrhhitghhrghrughsohhnsehinhhtvghlrdgtohhm pdhrtghpthhtohepshhtvghphhgvnhesnhgvthifohhrkhhplhhumhgsvghrrdhorhhgpd hrtghpthhtohepfhgvnhhgtghhvghnghifvghnsehhuhgrfigvihdrtghomhdprhgtphht thhopehkohhnshhtrghnthhinhdrrghnrghnhigvvheshhhurgifvghirdgtohhm X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 8 Nov 2024 17:13:04 -0500 (EST) From: Thomas Monjalon To: David Marchand , Mattias =?UTF-8?B?UsO2bm5ibG9t?= , Morten =?UTF-8?B?QnLDuHJ1cA==?= Cc: dev@dpdk.org, Bruce Richardson , Stephen Hemminger , Chengwen Feng , Konstantin Ananyev Subject: Re: [PATCH] config: limit lcore variable maximum size to 4k Date: Fri, 08 Nov 2024 23:13:02 +0100 Message-ID: <27009651.6Emhk5qWAg@thomas> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F8B4@smartserver.smartshare.dk> References: <20241108181732.173263-1-david.marchand@redhat.com> <98CBD80474FA8B44BF855DF32C47DC35E9F8B3@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9F8B4@smartserver.smartshare.dk> 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 20:53, Morten Br=C3=B8rup: > > From: Morten Br=C3=B8rup [mailto:mb@smartsharesystems.com] > > Sent: Friday, 8 November 2024 19.35 > >=20 > > > 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. >=20 > 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 an= d future). >=20 > > > 1M for each lcore translates to allocating 128M with default build > > > options on x86. > > > This resulted in OOM while running unit tests in parallel. >=20 > Is the root cause the lcore variables library itself, or the unit test us= ing 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. > >=20 > > 4 KB is not future proof. > >=20 > > Here's an example where 16 KB is cutting it close: > > https://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35E9F7D0@smart > > server.smartshare.dk/ > >=20 > > 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 footpr= int, 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.