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 8712D42993; Thu, 20 Apr 2023 09:43:37 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1BBBA40A4B; Thu, 20 Apr 2023 09:43:37 +0200 (CEST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by mails.dpdk.org (Postfix) with ESMTP id 19CD340687 for ; Thu, 20 Apr 2023 09:43:36 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 96F38320098C; Thu, 20 Apr 2023 03:43:32 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 20 Apr 2023 03:43:33 -0400 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:sender:subject:subject:to:to; s=fm3; t= 1681976612; x=1682063012; bh=IV5o/E4CNLDdxxQu1JDxf5PanOEGtrA2URE P2mwePbc=; b=Qvrjs6eD3CR33OORs3O1cunxjde2f6QanrL0lV82wRsBiITHS/5 6yRhWCM5OJjr3p+lcL9Be+KXEJEUNTvyy08JpydQdWfmEEg4qDQQwyibOB9p74PX 8Pk4cMUwYEg1JqZ41xO5ZqtPAfE1D1iAhxO5uvihMEi4l4SCgTgDkxj56T0DecB3 QjS7dpqCx+56wrGwfvB/Qo4FR9UrZX9aCD4KVHAO28ps0/bu8exkbZD7o1RxMUd4 4DLShDkqtgBKNciBibHfpzHUjXGRZbUufKsLrnLWiXp5D1qUxpTniJBg0JyXkpDM ijseORdblJyBa4Svvz2t1JddvD2sUR8o3gg== 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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1681976612; x=1682063012; bh=IV5o/E4CNLDdxxQu1JDxf5PanOEGtrA2URE P2mwePbc=; b=WxfV3WR6PwCF+VeVrflTgC283zKoFq+Zmy10AEBsmDfD6S6Nymh w+m6tHoJH0aydHh1SrdweYRszPwng2ATz8w0kp/G5wOonhN+dRZzXA6GRIcWvY6Q FSDI9U9AKiLPv+kDSusVwLU068g4GBYXb6z56D8TAamd8uD2nGGxWJHOFWSRhUCk vC4wFMAvv6OG99LviBPD7WrhCkw1QSlicZ6ejMDYwrNSCax6SQAQ2ake5D2phwRH 6i0UU34y9Qmzcp9DqHC8rQXrfv8fHdQg0vcQGdlsGeJDw8jps31fewnAPPNkstT6 0cl1a5OHnn31M6Ea/5uiQnWxlM7wRK4xJfQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfedtuddguddvgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvfevufffkfgjfhgggfgtsehtqhertddttdejnecuhfhrohhmpefvhhho mhgrshcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqne cuggftrfgrthhtvghrnhepgedttdeljeejgeffkeekkedtjeevtdehvedtkeeivdeuuedv ieduvdelveejueejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 20 Apr 2023 03:43:30 -0400 (EDT) From: Thomas Monjalon To: Tyler Retzlaff Cc: Ophir Munk , dev@dpdk.org, Bruce Richardson , Devendra Singh Rawat , Alok Prasad , Matan Azrad , Lior Margalit Subject: Re: [RFC] lib: set/get max memzone segments Date: Thu, 20 Apr 2023 09:43:28 +0200 Message-ID: <4891070.0VBMTVartN@thomas> In-Reply-To: <20230419145119.GA4687@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20230419083634.2027689-1-ophirmu@nvidia.com> <20230419145119.GA4687@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> 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 19/04/2023 16:51, Tyler Retzlaff: > On Wed, Apr 19, 2023 at 11:36:34AM +0300, 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 the max value via an r= te API - > > rather than changing the dpdk source code per application. In many > > organizations, the possibility to compile a private DPDK library for a > > particular application does not exist at all. With this option there is > > no need to recompile DPDK and it allows using an in-box packaged DPDK. > > An example usage for updating the RTE_MAX_MEMZONE 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 is not about how to optimize the application usage of > > mempool nor about how to improve the mempool implementation based on > > memzone. It is about how to make the max memzone definition - run-time > > customized. > > This commit adds an API which must be called before rte_eal_init(): > > rte_memzone_max_set(int max). If not called, the default memzone > > (RTE_MAX_MEMZONE) is used. There is also an API to query the effective > > max memzone: rte_memzone_max_get(). > >=20 > > Signed-off-by: Ophir Munk > > --- >=20 > the use case of each application may want a different non-hard coded > value makes sense. >=20 > it's less clear to me that requiring it be called before eal init makes > sense over just providing it as configuration to eal init so that it is > composed. Why do you think it would be better as EAL init option? =46rom an API perspective, I think it is simpler to call a dedicated functi= on. And I don't think a user wants to deal with it when starting the applicatio= n. > can you elaborate further on why you need get if you have a one-shot > set? why would the application not know the value if you can only ever > call it once before init? The "get" function is used in this patch by test and qede driver. The application could use it as well, especially to query the default value.