[dpdk-dev] [PATCH v5 1/2] eal: allow user to override default pool handle

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