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 88539429AE; Fri, 21 Apr 2023 16:57:16 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 755004113C; Fri, 21 Apr 2023 16:57:16 +0200 (CEST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by mails.dpdk.org (Postfix) with ESMTP id D9606410FB for ; Fri, 21 Apr 2023 16:57:14 +0200 (CEST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 3BA633200AF5; Fri, 21 Apr 2023 10:57:10 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Fri, 21 Apr 2023 10:57:11 -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= 1682089029; x=1682175429; bh=EBkxj1Xr0E/eruTR4eMhY7+Cxb4I/LbKUx4 +CMbHUS8=; b=VNDOs1cWM45/NIwsQ2pLQ813NQnoOHiZwprcyxQf7O+pMLlhSBb 9+qeCBtIfq5/5d+H4TpP0QImMDJrdl7Cszqdd6JX2heTLxIRoLTOzXwZKiBlgS7f Vb2zHi/AtR1DadAgdKmBTFex2YKu4FBTzSvKTBLFV7K5wWp5j4MjhhvOjkC0YE8O El7tzyA5L+lxTnLiLQoIrL9iZEYc4fdF+Q67RfitChzrBzTXOMvgQExLBZ2dW11K 56Z3cf0ZI4uFN2DyS2Isr8iBT31lZjl/ofbHxUh94JHC7cnZMPjMSshAsdbPyVFZ hSaVdzHK4VhmIUPwcyRzn5/bYc2EvO/EBhA== 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= 1682089029; x=1682175429; bh=EBkxj1Xr0E/eruTR4eMhY7+Cxb4I/LbKUx4 +CMbHUS8=; b=iZI3TuOCtprATfkrZUEJ0OTiErvv6FmJSKtZqtEnhGvN4mLMvqU Hu0O0+2UgI1pdYJgQvmGn6/1N498yJkDdQF1IInd4djHIe/IcXEkVTZJyZj1t245 CATDV2C+ygzOCGzb9fbnJIkFIdjgPr3ble/jYFKdS7e603HGIFhSfm+BuwZ5VEjU kw67EnpeVF6H/F6Fh6DVdiGgwNlpCzsbhod4dymeyunf6yUKJPynDTCFQuBPGkZa 9xI239kh+U43Anympidha6Tp1etxHX9+2tCL2DVCWMmHH2tT12Gh6jF+YibIxImK QJogiZbQuMcy7EjjD7cRdX6pQdrHUVOv1fA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfedtgedgkeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeegtddtleejjeegffekkeektdejvedtheevtdekiedvueeuvdei uddvleevjeeujeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 21 Apr 2023 10:57:08 -0400 (EDT) From: Thomas Monjalon To: Morten =?ISO-8859-1?Q?Br=F8rup?= Cc: Ophir Munk , dev@dpdk.org, Bruce Richardson , Devendra Singh Rawat , Alok Prasad , Matan Azrad , Lior Margalit , Tyler Retzlaff Subject: Re: [RFC] lib: set/get max memzone segments Date: Fri, 21 Apr 2023 16:57:06 +0200 Message-ID: <7647463.lvqk35OSZv@thomas> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D878A7@smartserver.smartshare.dk> References: <20230419083634.2027689-1-ophirmu@nvidia.com> <1796765.8hzESeGDPO@thomas> <98CBD80474FA8B44BF855DF32C47DC35D878A7@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 21/04/2023 13:08, Morten Br=C3=B8rup: > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > Sent: Friday, 21 April 2023 10.35 > > 20/04/2023 20:20, Tyler Retzlaff: > > > On Thu, Apr 20, 2023 at 09:43:28AM +0200, Thomas Monjalon wrote: > > > > 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 unconditional= ly 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 rte API > > - > > > > > > rather than changing the dpdk source code per application. In = many > > > > > > organizations, the possibility to compile a private DPDK librar= y 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 package= d DPDK. > > > > > > An example usage for updating the RTE_MAX_MEMZONE would be of an > > > > > > application that uses the DPDK mempool library which is based o= n 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 bas= ed 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_ini= t(): > > > > > > rte_memzone_max_set(int max). If not called, the default memzo= ne > > > > > > (RTE_MAX_MEMZONE) is used. There is also an API to query the > > effective > > > > > > max memzone: rte_memzone_max_get(). > > > > > > > > > > > > Signed-off-by: Ophir Munk > > > > > > --- > > > > > > > > > > the use case of each application may want a different non-hard co= ded > > > > > value makes sense. > > > > > > > > > > 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? > > > > From an API perspective, I think it is simpler to call a dedicated > > function. > > > > And I don't think a user wants to deal with it when starting the > > application. > > > > > > because a dedicated function that can be called detached from the eal > > > state enables an opportunity for accidental and confusing use outside > > > the correct context. > > > > > > i know the above prescribes not to do this but. > > > > > > now you can call set after eal init, but we protect about calling it > > > after init by failing. what do we do sensibly with the failure? > >=20 > > It would be a developer mistake which could be fix during development s= tage > > very easily. I don't see a problem here. >=20 > Why is this not just a command line parameter, like other EAL configurati= on options? >=20 > Do any other pre-init APIs exist, or are you introducing a new design pat= tern for configuring EAL? Let's say it is a "new" design pattern, as discussed multiple times in prev= ious years. But this one is only for the application, it is not a user configuration as in rte_eal_init(int argc, char **argv). > Any application can simply modify the command line parameters before call= ing EAL init. It doesn't need to pass the command line parameters as-is to = EAL init. It is not very easy to use. > In other words: There is an existing design pattern for configuring EAL, = why introduce a new design pattern? Because argc/argv is a bad pattern. We had multiple requests to avoid it. So when introducing a new option, it is better to avoid it. > If we want to expose APIs for configuring EAL instead of passing command = line parameters, such APIs should be added for all EAL configuration parame= ters. The memzone parameter is not supposed to be configured by the user, so it does not make sense to expose it via argc/argv. > That would be nice, but I dislike that some EAL configuration parameters = must be passed using one method and some other passed using another method. We asked multiple times for such rework. And the patches from Bruce to split some EAL parts are in this direction. If you want to propose some new functions to configure EAL, you are welcome.