From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <olivier.matz@6wind.com>
Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67])
by dpdk.org (Postfix) with ESMTP id 462681B1AB
for <dev@dpdk.org>; Tue, 16 Jan 2018 16:04:23 +0100 (CET)
Received: from lfbn-lil-1-110-231.w90-45.abo.wanadoo.fr ([90.45.197.231]
helo=droids-corp.org)
by mail.droids-corp.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256)
(Exim 4.89) (envelope-from <olivier.matz@6wind.com>)
id 1ebSmn-0000JT-JN; Tue, 16 Jan 2018 16:04:27 +0100
Received: by droids-corp.org (sSMTP sendmail emulation);
Tue, 16 Jan 2018 16:04:20 +0100
Date: Tue, 16 Jan 2018 16:04:20 +0100
From: Olivier Matz <olivier.matz@6wind.com>
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Cc: Hemant Agrawal <hemant.agrawal@nxp.com>, dev@dpdk.org,
santosh.shukla@caviumnetworks.com
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
Content-Disposition: inline
In-Reply-To: <20180115162635.GC1245@jerin>
User-Agent: NeoMutt/20170113 (1.7.2)
Subject: Re: [dpdk-dev] [PATCH v2 2/5] eal: add platform mempool ops name in
internal config
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jan 2018 15:04:23 -0000
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 <hemant.agrawal@nxp.com>
> > To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > 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?