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 4C50D41C89; Mon, 13 Feb 2023 14:55:48 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 390F140A81; Mon, 13 Feb 2023 14:55:48 +0100 (CET) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by mails.dpdk.org (Postfix) with ESMTP id 8FDA8400D6 for ; Mon, 13 Feb 2023 14:55:46 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 2B1A75C00F3; Mon, 13 Feb 2023 08:55:45 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 13 Feb 2023 08:55:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1676296545; x= 1676382945; bh=5Ei+CvejEwLSZNuuMx/qeXKSBA9f8ZjDQqb6mV3OUOQ=; b=k wsj5A9UZcNrWylGVKNSYWtU6EMHP9zDQ4IU4JhMCBrGre1sTvQ2cBhVYqdP6k+rv JTCpVeZ8xB+0UmksNAcEsXB4QX9vwDSdyhwVFmk0iqvTC4sM3F7X5RHd/PLKzT1G 7n5U7lGZZJQvCMt6brBXMbeAGvxxFm2mP62HAO1YBm0wPeyDqkqL1K+ePYm8ruu4 dw72d09E6/7UPCsb8MeqNNhK29BhcTEBBRTnnTtPJ2btjK4+wFtxoqf4LhyYZn/c 31KSkdqEopuj5D8cdIdlnVQSvUhQW7t5iOQG5JG7mUK1ODRZ7uhiHfEOQXnqY9gC 1R3DAC4k0Np1Ou7vyS8Ig== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1676296545; x= 1676382945; bh=5Ei+CvejEwLSZNuuMx/qeXKSBA9f8ZjDQqb6mV3OUOQ=; b=i fRVAQtATNupJy4+rmOAzNNAuV/Cv8Wc1BJdgVRzDoMr+5aMYsPLmNOaYb579AjzO u9vxADqQgiKwm3VoGJT18xj5ZKSjTWZnXYqXurDcXM2xJgIxd55WHHaW1TAl6LoH kyUadgwZFt4FOYOzpaTo5VBSocGwyFwmO28J7nEWm1kYlgXXU+dWjtjWzHWDXULy wvq8CzXr2mnISM41vh0FzUbxkLQOHRY7r1UlHrt+whnc1RhMqXp2YTHSPpAfboOT Xd97H3vtqLC3CPFqWAkr63E3A3N/E+AfiVwxOTE8KLoa9mQkExO8Xd+WYwyQRXfo QOoui96FSZlbzxVzPd46g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudeiuddgheehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpefftdeuhfehvdekleelveffvdelhfelhedvgedtvddvudeuieev tdfgjedvudegfeenucffohhmrghinhepughpughkrdhorhhgnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 13 Feb 2023 08:55:43 -0500 (EST) From: Thomas Monjalon To: Ophir Munk , Bruce Richardson Cc: dev@dpdk.org, Matan Azrad , Lior Margalit , Asaf Penso , david.marchand@redhat.com, honnappa.nagarahalli@arm.com, jerinj@marvell.com Subject: Re: [PATCH v1] config: make max memzones definition configurable Date: Mon, 13 Feb 2023 14:55:41 +0100 Message-ID: <3111936.fEcJ0Lxnt5@thomas> In-Reply-To: References: <20230212085319.693689-1-ophirmu@nvidia.com> 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 13/02/2023 12:05, Bruce Richardson: > On Sun, Feb 12, 2023 at 10:53:19AM +0200, Ophir Munk wrote: > > In current DPDK the RTE_MAX_MEMZONE definition is unconditionally hard > > coded as 2560. For applications requiring different values of this > > parameter =E2=80=93 it is more convenient to set its value as part of t= he meson > > command line rather than changing the dpdk source code per application. > > An example would be of an application that uses the DPDK mempool library > > which is based on DPDK memzone library. The application may need to > > create a number of steering tables, each of which will require its own > > mempool allocation. > > This commit adds a meson optional parameter named max_memzones. If not > > specified - it is set by default to 2560. The hard coded definition of > > RTE_MAX_MEMZONE is removed. During meson build time the RTE_MAX_MEMZONE > > can be optionally defined as the value of max_memzones parameter. > >=20 > > Signed-off-by: Ophir Munk > > --- > > RFC: > > https://patchwork.dpdk.org/project/dpdk/patch/20230130092302.376145-1-o= phirmu@nvidia.com/ > >=20 > > config/meson.build | 1 + > > config/rte_config.h | 1 - > > meson_options.txt | 2 ++ > > 3 files changed, 3 insertions(+), 1 deletion(-) > >=20 > Acked-by: Bruce Richardson Are we going to move all compilation-defined settings to meson_options.txt? The direction discussed in recent years was to configure things at runtime, and stop adding compilation-time settings. In this case, it is quite easy to add a new function void rte_memzone_set_max(int max) to be called before rte_eal_init(). If not called, the historical default is used.