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 D6303A0C4C; Thu, 14 Oct 2021 10:29:39 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C00524115E; Thu, 14 Oct 2021 10:29:39 +0200 (CEST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by mails.dpdk.org (Postfix) with ESMTP id 3E9C440041 for ; Thu, 14 Oct 2021 10:29:39 +0200 (CEST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 087D432007F0; Thu, 14 Oct 2021 04:29:37 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 14 Oct 2021 04:29:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= Zhmx3mzh8yz3oVjgBm6tvbu2X6K/Tsr+oYCkewjYE+o=; b=qQ7DJCPBvMiMgiqs h3cD8D9IpMa2CPDYVVghA+l+pKMhqPMCVBPfPmpjSPp0xWC2ZJ5vBAgscceqlFvt 4msF7BiYkDGSDOOAf1+QuLk0jGlnv7JjpblrshrZftztgyVPBRMTkKt3Ey7t/mds ZLnlIXXmiKufzsbIlWhlrRFHp3jgYmnRZLV07ZqpLyimRTgpxUmHn5TK2Y3WJNs1 8XaYqJHzpnmd8DPB891QjIhO47aKeSuv5mkPT8Ad0gUJwf5yljwveVRyar+9dfzL +fiemRPGeaINADuF7gdWDi+HScjW2JuA9UELSZhUKQlTBE3ka3Wko0P2BH1Qiu+X MdrU0g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=Zhmx3mzh8yz3oVjgBm6tvbu2X6K/Tsr+oYCkewjYE +o=; b=LWk5PY834rjat0CdTAJDFZqEvI0qyciYKCc6hh/9tlOq48D/u1gFnweat RDQncb6ojBVD/JiZPNTSgw+Vq1WlkVOMSDUBbM2Whdfm4SSbjRmzOu1SLVIHlaAv 1y+x+GU41SyWuTm8SdCU3fU5Vi3tGpWD0oBWGCbXvoJ+u9rDf9zBfW62r7A7sWZy 45ma8SCUak4S8YAUT2+8iAnKqcNNMM/e0Iu1IJw+/cu+tVpFppTsN1eA+f/alqIl B91FLkoBqzdqPznb3eTmtkh9cJPj4p8zIzr8KkRIqp7Du91dMANXvqAEyVoYtpd+ LNdtx2vUkCwQU18B44P06MZDI42Ww== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdduvddgtdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 14 Oct 2021 04:29:35 -0400 (EDT) From: Thomas Monjalon To: Kefu Chai , Bruce Richardson Cc: dev@dpdk.org, Avi Kivity , anatoly.burakov@intel.com Date: Thu, 14 Oct 2021 10:29:34 +0200 Message-ID: <2642296.XfZ1dg20Xv@thomas> In-Reply-To: References: <20210902144805.105098-1-tchaikov@gmail.com> <20211013205417.84119-3-tchaikov@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v5 2/2] build: add meson options of max_memseg_lists 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 Sender: "dev" 14/10/2021 10:25, Bruce Richardson: > On Thu, Oct 14, 2021 at 04:54:19AM +0800, Kefu Chai wrote: > > RTE_MAX_MEMSEG_LISTS = 128 is not enough for many-core machines, in our > > case, we need to increase it to 8192. so add an option so user can > > override it. > > > > Signed-off-by: Kefu Chai > > This seems a very low-level option to be exposing to the user. Some > thoughts/questions: > > - can you give some more detail on why you need such a massive number, 64 > times the default? > - what would be the impact of increasing the default to 8192? I assume this > is only used in a few places in EAL, so would the memory footprint > increase be large? > - rather than a single specified value, would an alternative be to make > this be a computed value at config time, scaled by number of lcores (or > number of numa nodes)? +1 for these suggestions