From mboxrd@z Thu Jan  1 00:00:00 1970
From: santosh <santosh.shukla@caviumnetworks.com>
Subject: Re: [PATCH v5 1/2] eal: allow user to override default
 pool handle
Date: Fri, 6 Oct 2017 09:01:07 +0530
Message-ID: <838da98a-47aa-efce-fb98-304e236fa5c6@caviumnetworks.com>
References: <20170911151837.25092-1-santosh.shukla@caviumnetworks.com>
 <20171001091440.10232-1-santosh.shukla@caviumnetworks.com>
 <20171001091440.10232-2-santosh.shukla@caviumnetworks.com>
 <1712938.NqKmOO8lQc@xps>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Cc: dev@dpdk.org, olivier.matz@6wind.com, jerin.jacob@caviumnetworks.com,
 hemant.agrawal@nxp.com
To: Thomas Monjalon <thomas@monjalon.net>
Return-path: <dev-bounces@dpdk.org>
Received: from NAM02-BL2-obe.outbound.protection.outlook.com
 (mail-bl2nam02on0054.outbound.protection.outlook.com [104.47.38.54])
 by dpdk.org (Postfix) with ESMTP id E7C1E1B216
 for <dev@dpdk.org>; Fri,  6 Oct 2017 05:31:28 +0200 (CEST)
In-Reply-To: <1712938.NqKmOO8lQc@xps>
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>


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.
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.
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_=.