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