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 5BC2341CFC; Tue, 21 Feb 2023 11:28:16 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4C7D8431B4; Tue, 21 Feb 2023 11:28:16 +0100 (CET) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id AA348406A2 for ; Tue, 21 Feb 2023 11:28:14 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 54DB15C00CB; Tue, 21 Feb 2023 05:28:14 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 21 Feb 2023 05:28:14 -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=1676975294; x= 1677061694; bh=BaVKcIoR80NS2f3tNrInc2FopIXuTfLKo+r5pT4Qq4I=; b=g SiIaRaEGMiotb4NsZ3ztA2ZgHctwAV0eRIKlxV4QpwCCNkHm+IACzVPlABHqa3Yk mpIanXasp//zILbPnAHqRG6bToVpLLmKLd6t6is1NyNRw5Qxn84aRiHB/uOiGlYQ Z6Icn6qEPjgG6Y/oy+FyCL4H5fZ0RFGcbLvWkfUqRyqAC7uElDLHn30eSVcwC3yH /jbCVNpYS7KjcPoHMSG3HxhxJlYHjyjVk1C6ghqbNB8bIsbTkJeR1pGvHT/D7aEq 3vqjvtWKCdxfbsl4cLW3J1sCUELupwGeS8ne78Bt/TO0RZC5Xf3SWuNiCxAFkrvK sClKrOCHDDaxycjuqf8aQ== 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=1676975294; x= 1677061694; bh=BaVKcIoR80NS2f3tNrInc2FopIXuTfLKo+r5pT4Qq4I=; b=W ODh5jIGHC/ttQHj9hP2oc0gmQ+dnkvoyDVyhZKnWkoqKxBsvPJVYd+TbCR/1z93z Obk1DsHTqz4Lhvvb7oBkw38gTop/0m8DHE6QUee0H3seTZJeYwhNgWeb3KGRW4U5 oJggqig++uQfGeA+mWAyiXtx25LHbF8EDUPnoClxnHIe7i6+Uoxskr7WUAXyAsmB S1o0FGV/RGAXupuILEap5tOQv8AN2NOPqYdCeJDZ/MvuN513XW5P4FPRCL2gct/6 uyEdqTuBlQ9LuKFfdl7+FZhqWEvCW6tIsO6jlwlM7gEDTyuwElWQPsH0WnSSKcBB e0QYaVrSTUzQbXEOW6LLQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudejjedgudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpefftdeuhfehvdekleelveffvdelhfelhedvgedtvddvudeuieev tdfgjedvudegfeenucffohhmrghinhepughpughkrdhorhhgnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 21 Feb 2023 05:28:12 -0500 (EST) From: Thomas Monjalon To: Ophir Munk Cc: Bruce Richardson , dev@dpdk.org, Matan Azrad , Lior Margalit , Asaf Penso , "david.marchand@redhat.com" , "honnappa.nagarahalli@arm.com" , "jerinj@marvell.com" , "rmody@marvell.com" , "dsinghrawat@marvell.com" Subject: Re: [PATCH v1] config: make max memzones definition configurable Date: Tue, 21 Feb 2023 11:28:11 +0100 Message-ID: <1890409.VZ3vTMCxA0@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 18:04, Ophir Munk: > Since the new rte API was "discussed in recent years" and it is also depe= ndent on different driver vendors acceptance - I suggest that the compilati= on option will be applied now. I think there is a misunderstanding here. > The new rte API effort will start in parallel. Once accepted - it will re= place the compilation option. The effort is just adding a single simple function. I can work on it. > From: Bruce Richardson > > On Mon, Feb 13, 2023 at 02:55:41PM +0100, Thomas Monjalon wrote: > > > 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 valu= e as part > > > > > of the 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. > > > > > > > > > > Signed-off-by: Ophir Munk --- RFC: > > > > > > > https://patchwork.dpdk.org/project/dpdk/patch/20230130092302.37614 > > > > > 5-1-ophirmu@nvidia.com/ > > > > > > > > > > config/meson.build | 1 + config/rte_config.h | 1 - > > > > > meson_options.txt | 2 ++ 3 files changed, 3 insertions(+), 1 > > > > > deletion(-) > > > > > > > > > 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 setting= s. > > > > > > 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. > > > > > Good point, I admit I had forgotten that. > >=20 > > Looking at the use of RTE_MAX_MEMZONE, it is used as an array dimension > > in a number of places, but, from what I see on cursory examination, it = should > > be replacable with a runtime value without significant pain in most cas= es. > > The one that probably needs more attention is the fact that the "net/qe= de" > > driver maintains an array of memzones in it's base-code layer. Therefor= e, we > > probably need input from that driver maintainer to know the impact there > > and why that array is needed in a net driver. [Adding the two maintaine= rs on > > CC] > >=20 > > /Bruce >=20