From mboxrd@z Thu Jan 1 00:00:00 1970 From: santosh Subject: Re: [PATCH v4 1/2] eal: allow user to override default pool handle Date: Mon, 25 Sep 2017 22:23:24 +0100 Message-ID: References: <20170815080717.9413-1-santosh.shukla@caviumnetworks.com> <20170911151837.25092-1-santosh.shukla@caviumnetworks.com> <20170911151837.25092-2-santosh.shukla@caviumnetworks.com> <20170925072840.uyphm7flinn33suj@platinum> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org, thomas@monjalon.net, jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com To: Olivier MATZ Return-path: Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0069.outbound.protection.outlook.com [104.47.42.69]) by dpdk.org (Postfix) with ESMTP id A231C3230 for ; Mon, 25 Sep 2017 23:23:47 +0200 (CEST) In-Reply-To: <20170925072840.uyphm7flinn33suj@platinum> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Monday 25 September 2017 08:28 AM, Olivier MATZ wrote: > On Mon, Sep 11, 2017 at 08:48:36PM +0530, Santosh Shukla wrote: >> DPDK has support for both sw and hw mempool and >> currently user is limited to use ring_mp_mc pool. >> In case user want to use other pool handle, >> need to update config RTE_MEMPOOL_OPS_DEFAULT, then >> build and run with desired pool handle. >> >> Introducing eal option to override default pool handle. >> >> Now user can override the RTE_MEMPOOL_OPS_DEFAULT by passing >> pool handle to eal `--mbuf-pool-ops=""`. >> >> Signed-off-by: Santosh Shukla >> Acked-by: Hemant Agrawal >> >> [...] >> >> --- a/lib/librte_eal/common/eal_internal_cfg.h >> +++ b/lib/librte_eal/common/eal_internal_cfg.h >> @@ -82,7 +82,7 @@ struct internal_config { >> volatile enum rte_intr_mode vfio_intr_mode; >> const char *hugefile_prefix; /**< the base filename of hugetlbfs files */ >> const char *hugepage_dir; /**< specific hugetlbfs directory to use */ >> - >> + const char *mbuf_pool_name; /**< mbuf pool name */ >> unsigned num_hugepage_sizes; /**< how many sizes on this system */ >> struct hugepage_info hugepage_info[MAX_HUGEPAGE_SIZES]; >> }; > What do you think about mbuf_pool_ops_name instead? > > I'm afraid of the confusion we could have with the name > of the mempool. > Hoping that we're doing final renaming on handle, Its the third time and so for other mempool series. queued for v5.