From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier Matz Subject: Re: [PATCH v2 2/5] eal: add platform mempool ops name in internal config Date: Tue, 16 Jan 2018 16:04:20 +0100 Message-ID: <20180116150420.loaa43j2u2fwmpzv@platinum> References: <1513333483-4372-1-git-send-email-hemant.agrawal@nxp.com> <1515996674-26338-1-git-send-email-hemant.agrawal@nxp.com> <1515996674-26338-3-git-send-email-hemant.agrawal@nxp.com> <20180115122445.GB29114@jerin> <90315b96-e3a1-b47c-935c-e6437cef2716@nxp.com> <20180115162635.GC1245@jerin> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Hemant Agrawal , dev@dpdk.org, santosh.shukla@caviumnetworks.com To: Jerin Jacob Return-path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id 462681B1AB for ; Tue, 16 Jan 2018 16:04:23 +0100 (CET) Content-Disposition: inline In-Reply-To: <20180115162635.GC1245@jerin> 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 Mon, Jan 15, 2018 at 09:56:36PM +0530, Jerin Jacob wrote: > -----Original Message----- > > Date: Mon, 15 Jan 2018 20:01:14 +0530 > > From: Hemant Agrawal > > To: Jerin Jacob > > CC: dev@dpdk.org, olivier.matz@6wind.com, santosh.shukla@caviumnetworks.com > > Subject: Re: [PATCH v2 2/5] eal: add platform mempool ops name in internal > > config > > User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 > > Thunderbird/45.8.0 > > > > On 1/15/2018 5:54 PM, Jerin Jacob wrote: > > > > static int > > > > diff --git a/lib/librte_eal/common/eal_internal_cfg.h b/lib/librte_eal/common/eal_internal_cfg.h > > > > index 1169fcc..12c5b8a 100644 > > > > --- a/lib/librte_eal/common/eal_internal_cfg.h > > > > +++ b/lib/librte_eal/common/eal_internal_cfg.h > > > > @@ -54,6 +54,8 @@ struct internal_config { > > > > const char *hugepage_dir; /**< specific hugetlbfs directory to use */ > > > > const char *user_mbuf_pool_ops_name; > > > > /**< user defined mbuf pool ops name */ > > > > + const char *plat_mbuf_pool_ops_name; > > > > + /**< platform configured mbuf pool ops name */ > > > > unsigned num_hugepage_sizes; /**< how many sizes on this system */ > > > > struct hugepage_info hugepage_info[MAX_HUGEPAGE_SIZES]; > > > > }; > > > > diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map > > > > index 3fa1e13..909691f 100644 > > > > --- a/lib/librte_eal/rte_eal_version.map > > > > +++ b/lib/librte_eal/rte_eal_version.map > > > > @@ -203,6 +203,7 @@ DPDK_17.11 { > > > > DPDK_18.02 { > > > > global: > > > > > > > > + internal_config; > > > > > > I think, exposing the internal_config may not be a good idea. We may > > > need "plat_mbuf_pool_ops_name" value for multi process case too. > > > Considering the above points, How about adding it in > > > struct rte_config and then expose too rte_eal_get_configuration() > > > On the downside, it would be an ABI change. > > > > Yes! I was also not sure about exposing internal_config. > > > > rte_config is also a good option. If we add these options in the end, it > > should not break ABI? > > I think, it does break the ABI. What about a new API in librte_mbuf as suggested as a reply to the cover letter?