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 B8B36429AA; Fri, 21 Apr 2023 10:35:04 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 46595410F3; Fri, 21 Apr 2023 10:35:04 +0200 (CEST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by mails.dpdk.org (Postfix) with ESMTP id 73074410DD for ; Fri, 21 Apr 2023 10:35:02 +0200 (CEST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 199D75C0129; Fri, 21 Apr 2023 04:35:02 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Fri, 21 Apr 2023 04:35:02 -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= 1682066102; x=1682152502; bh=8lzhl5V7Pmi5e0xnErBmnJ0T3Q5kYR8+BlQ 1qM992pQ=; b=MKDK3xtIHlp2IdTbvzGIzELwUCowIzbe3RxDvgxpcfJaYN3uHUl P37mY4e0JOgm7lMUKvjC6Y2NpBHqSU4J2uOGjkLFUwboE6rOh4BA6YAcqxSM42wD Pc/cTzolptXSKPS3KtLj7o9kJR067Ue+ThP+Uv74LmzvzzrG/d0R9x7Pfc3swQli MrIJwnej8M0lsewD52aZMj4k+sUybL9s3pRMrmrKbf15nH2edi/EOktQs78iZmzF LXUb1Ik282MSdCuSgBJGTqW7thYMmHZJaw1ZE2nErgvwrcqIso8vVA0/+yeRsG1L cJRDTSwQ4jsQ+iB68CP0bM11TzDZ8VyB9gA== 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= 1682066102; x=1682152502; bh=8lzhl5V7Pmi5e0xnErBmnJ0T3Q5kYR8+BlQ 1qM992pQ=; b=gZxvlKiQBq6JK1M05Zj+wt7pkK51zlCrja1INxwdWhyvFJc3dXZ TToqlFHsbSFs5aLP17D942AyWKZbm2kCEHGzC1rjqdfd1+ZOOjWwvzjyK/Xp9jk1 GqbfAHPU1rfrPJ06L5ZF5yCh5agY2R+ajwMi8UEHkxzopeQplzjok/wHtJW6npNZ sZP771l0VzijDJrcu969fnbaqmsLzB/2ccJpAlxsNIyBvV981EwrfkVBatTrDzhb uZm/AwlUyn5vC0bk9Md6SVD16N/+adiGRRpjZQKkcYYUtqhSrmJ/aMqJ79SgwNBp +efPrD0eVurnVu+r27LiXzHoX3C/a9h/WOQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfedtgedgtdegucetufdoteggodetrfdotf 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 04:35:00 -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: Fri, 21 Apr 2023 10:34:59 +0200 Message-ID: <1796765.8hzESeGDPO@thomas> In-Reply-To: <20230420182043.GA30650@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20230419083634.2027689-1-ophirmu@nvidia.com> <4891070.0VBMTVartN@thomas> <20230420182043.GA30650@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 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 unconditionally h= ard > > > > 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 library fo= r a > > > > particular application does not exist at all. With this option the= re is > > > > no need to recompile DPDK and it allows using an in-box packaged DP= DK. > > > > An example usage for updating the RTE_MAX_MEMZONE would be of an > > > > application that uses the DPDK mempool library which is based on DP= DK > > > > memzone library. The application may need to create a number of > > > > steering tables, each of which will require its own mempool allocat= ion. > > > > 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 effec= tive > > > > 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 mak= es > > > sense over just providing it as configuration to eal init so that it = is > > > composed. > >=20 > > 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 func= tion. > > And I don't think a user wants to deal with it when starting the applic= ation. >=20 > 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. >=20 > i know the above prescribes not to do this but. >=20 > 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? It would be a developer mistake which could be fix during development stage very easily. I don't see a problem here. > > > 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? > >=20 > > 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 v= alue. >=20 > this seems incoherent to me, why does the application not know if it has > called set or not? if it called set it knows what the value is, if it did= n't > call set it knows what the default is. No the application doesn't know the default, it is an internal value. > anyway, the use case is valid and i would like to see the ability to > change it dynamically i'd prefer not to see an api like this be introduced > as prescribed but that's for you folks to decide. >=20 > anyway, i own a lot of apis that operate just like the proposed and > they're great source of support overhead. i prefer not to rely on > documenting a contract when i can enforce the contract and implicit state > machine mechanically with the api instead. >=20 > fwiw a nicer pattern for doing this one of framework influencing config > might look something like this. >=20 > struct eal_config config; >=20 > eal_config_init(&config); // defaults are set entire state made valid > eal_config_set_max_memzone(&config, 1024); // default is overridden >=20 > rte_eal_init(&config); In general, we discovered that functions doing too much are bad for usability and for ABI stability. In the function eal_config_init() that you propose, any change in the struct eal_config will be an ABI breakage.