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 539E64299C; Thu, 20 Apr 2023 20:20:46 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0BFAE40697; Thu, 20 Apr 2023 20:20:46 +0200 (CEST) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 8D9E340687 for ; Thu, 20 Apr 2023 20:20:44 +0200 (CEST) Received: by linux.microsoft.com (Postfix, from userid 1086) id D4AF421C209F; Thu, 20 Apr 2023 11:20:43 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com D4AF421C209F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1682014843; bh=a+F83sqmxmnzNLuFXi+p06aCECJsMScMytFa8zzYGv8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kx8+8xfyK1RsBVIjsFpR1wS4cr9FAcJTi1mRC8RuvaPcDn1IBUpPo8kbp3R5iCnbN 3MGyUApaVUDkzjxaIljEdThmQyQgpGBmmGu+CcntzoIY7qx7FxlVTX2ycBAcr2lCOr D699srAhKt66lemNqqNTnGCwy7AOjMUEGWppOAFc= Date: Thu, 20 Apr 2023 11:20:43 -0700 From: Tyler Retzlaff To: Thomas Monjalon 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 Message-ID: <20230420182043.GA30650@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20230419083634.2027689-1-ophirmu@nvidia.com> <20230419145119.GA4687@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <4891070.0VBMTVartN@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4891070.0VBMTVartN@thomas> User-Agent: Mutt/1.5.21 (2010-09-15) 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 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 hard > > > coded as 2560. For applications requiring different values of this > > > parameter – 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 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(). > > > > > > Signed-off-by: Ophir Munk > > > --- > > > > the use case of each application may want a different non-hard coded > > 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? > > > 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. 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 didn't call set it knows what the default is. 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. 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. fwiw a nicer pattern for doing this one of framework influencing config might look something like this. struct eal_config config; eal_config_init(&config); // defaults are set entire state made valid eal_config_set_max_memzone(&config, 1024); // default is overridden rte_eal_init(&config); ty