[dpdk-dev] [PATCH 1/2] mbuf: update default Mempool ops with HW active pool

[Hemant Agrawal]

On 12/18/2017 2:25 PM, Jerin Jacob wrote:
> -----Original Message-----
>> Date: Fri, 15 Dec 2017 15:54:42 +0530
>> From: Hemant Agrawal <hemant.agrawal at nxp.com>
>> To: olivier.matz at 6wind.com, santosh.shukla at caviumnetworks.com
>> CC: dev at dpdk.org
>> Subject: [dpdk-dev] [PATCH 1/2] mbuf: update default Mempool ops with HW
>>  active pool
>> X-Mailer: git-send-email 2.7.4
>>
>> With this patch the specific HW mempool are no longer required to be
>> specified in the config file at compile. A default active hw mempool
>> can be detected dynamically and published to default mempools ops
>> config at run time. Only one type of HW mempool can be active default.
>
> For me, it looks very reasonable approach as it caters the basic use
> case without any change in the application nor the additional(--mbuf-pool-ops-name)
> EAL command line scheme to select different mempool ops.
> Though, this option will not enough cater all the use case. I think, we can have
> three options and the following order of precedence to select the mempool ops
>
> 1) This patch(update active mempool based on the device probe())
> 2) Selection of mempool ops though --mbuf-pool-ops-name= EAL commandline argument.
> Which can overridden the scheme(1)
> 3) More sophisticated mempool section based on
> a) The ethdev PMD capability exposed through existing rte_eth_dev_pool_ops_supported()
> b) Add mempool ops option in rte_pktmbuf_pool_create()
> http://dpdk.org/ml/archives/dev/2017-December/083985.html
> c) Use (a) and (b) to select the update the mempool ops with
> some "weight" based algorithm like
> http://dpdk.org/dev/patchwork/patch/32245/
>

Yes! We need more options to fine tune control over the mempool uses, 
specially when dealing with HW mempools.

Once the above mentioned mechanisms will be in place, it will be much 
easier and flexible.

>>
>> Signed-off-by: Hemant Agrawal <hemant.agrawal at nxp.com>
>> ---
>>  lib/librte_mbuf/rte_mbuf.c | 33 ++++++++++++++++++++++++++++++++-
>>  lib/librte_mbuf/rte_mbuf.h | 13 +++++++++++++
>>  2 files changed, 45 insertions(+), 1 deletion(-)
>>
>> diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
>> index 7543662..e074afa 100644
>> --- a/lib/librte_mbuf/rte_mbuf.c
>> +++ b/lib/librte_mbuf/rte_mbuf.c
>> @@ -148,6 +148,37 @@ rte_pktmbuf_init(struct rte_mempool *mp,
>>  	m->next = NULL;
>>  }
>>
>> +static const char *active_mbuf_pool_ops_name;
>
> Global variable will create issue in multi process case.
>
>> +
>> +int
>> +rte_pktmbuf_reg_active_mempool_ops(const char *ops_name)
>> +{
>> +	if (active_mbuf_pool_ops_name == NULL) {
>> +		active_mbuf_pool_ops_name = ops_name;
>
> I think, if we could update "internal_config.mbuf_pool_ops_name" value then
> we don't need any extra global variable.
>
>
That is a good suggestion.
Also, We may need additional variable in internal config to indicate 
that this is a application provided ops_name - so that it should not be 
overwritten.