From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [PATCH v5 1/2] eal: allow user to override default
	pool handle
Date: Fri, 06 Oct 2017 10:39:39 +0200
Message-ID: <16755451.xTlTRoHbfF@xps>
References: <20170911151837.25092-1-santosh.shukla@caviumnetworks.com>
 <1712938.NqKmOO8lQc@xps>
 <838da98a-47aa-efce-fb98-304e236fa5c6@caviumnetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: dev@dpdk.org, olivier.matz@6wind.com, jerin.jacob@caviumnetworks.com,
 hemant.agrawal@nxp.com
To: santosh <santosh.shukla@caviumnetworks.com>
Return-path: <dev-bounces@dpdk.org>
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com
 [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id EA7AF1B259
 for <dev@dpdk.org>; Fri,  6 Oct 2017 10:39:40 +0200 (CEST)
In-Reply-To: <838da98a-47aa-efce-fb98-304e236fa5c6@caviumnetworks.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://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: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

06/10/2017 05:31, santosh:
> 
> On Friday 06 October 2017 05:59 AM, Thomas Monjalon wrote:
> > 01/10/2017 11:14, Santosh Shukla:
> >> --- a/lib/librte_eal/common/eal_common_options.c
> >> +++ b/lib/librte_eal/common/eal_common_options.c
> >> @@ -98,6 +98,7 @@ eal_long_options[] = {
> >>  	{OPT_VFIO_INTR,         1, NULL, OPT_VFIO_INTR_NUM        },
> >>  	{OPT_VMWARE_TSC_MAP,    0, NULL, OPT_VMWARE_TSC_MAP_NUM   },
> >>  	{OPT_XEN_DOM0,          0, NULL, OPT_XEN_DOM0_NUM         },
> >> +	{OPT_MBUF_POOL_OPS_NAME, 1, NULL, OPT_MBUF_POOL_OPS_NAME_NUM},
> >>  	{0,                     0, NULL, 0                        }
> >>  };
> > I think the options were sorted alphabetically.
> 
> This is most logical comment so far I got from you.

I will imagine you did not really write this.

> Yes' will do. posting v6. Thanks.
> 
> > [...]
> >> --- 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_ops_name;   /**< mbuf pool ops name */
> > Why this config is not stored in mbuf.c?
> >
> Why the config not stored for vfio? hugepage? etc..in that case applicable too.

All other configs are related to EAL features.

> This is correct place to keep for now, unless as discussed in dpdksummit about eal
> parsing abstraction approach.. plugin style approach so that each module has its own
> parser. till then It should sit here like other, Its blocker for external-mempool
> in general case: Where users are forced to hard-code their handle in _OPS_DEFAULT_=.

You probably missed that mbuf is not part of EAL.
I'm not talking about parsers, just where to save a variable.
You store mbuf info in EAL, and later, call
rte_eal_mbuf_default_mempool_ops() from mbuf lib.
It would be saner to directly save it in mbuf lib.

But Olivier agreed to save mbuf config in EAL.
I won't discuss it anymore if you don't want to change.