[dpdk-dev] [PATCH 0/2] Allow application set mempool handle

santosh santosh.shukla at caviumnetworks.com
Tue Jul 4 14:25:54 CEST 2017


Hi Olivier,

On Friday 30 June 2017 07:42 PM, Olivier Matz wrote:

> Hi,
>
> On Tue, 20 Jun 2017 19:34:15 +0530, Jerin Jacob <jerin.jacob at caviumnetworks.com> wrote:
>> -----Original Message-----
>>> Date: Tue, 20 Jun 2017 16:07:17 +0530
>>> From: Hemant Agrawal <hemant.agrawal at nxp.com>
>>> To: Jerin Jacob <jerin.jacob at caviumnetworks.com>
>>> CC: Santosh Shukla <santosh.shukla at caviumnetworks.com>,
>>>  olivier.matz at 6wind.com, dev at dpdk.org
>>> Subject: Re: [PATCH 0/2] Allow application set mempool handle
>>> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
>>>  Thunderbird/45.8.0
>>>
>>> On 6/19/2017 6:31 PM, Jerin Jacob wrote:  
>>>> -----Original Message-----  
>>>>> Date: Mon, 19 Jun 2017 17:22:46 +0530
>>>>> From: Hemant Agrawal <hemant.agrawal at nxp.com>
>>>>> To: Santosh Shukla <santosh.shukla at caviumnetworks.com>,
>>>>>  olivier.matz at 6wind.com, dev at dpdk.org
>>>>> CC: jerin.jacob at caviumnetworks.com
>>>>> Subject: Re: [PATCH 0/2] Allow application set mempool handle
>>>>> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
>>>>>  Thunderbird/45.8.0
>>>>>
>>>>> On 6/1/2017 1:35 PM, Santosh Shukla wrote:  
>>>>>> Some platform can have two different NICs for example external PCI Intel
>>>>>> 40G card and Integrated NIC like vNIC/octeontx/dpaa2.
>>>>>>
>>>>>> Both NICs like to use their preferred pool e.g. external PCI card/ vNIC's
>>>>>> preferred pool would be the ring based pool and octeontx/dpaa2 preferred would
>>>>>> be ext-mempools.
>>>>>> Right now, Framework doesn't support such case. Only one pool can be
>>>>>> used across two different NIC's. For that, user has to statically set
>>>>>> CONFIG_RTE_MEMPOOL_DEFAULT_OPS=<pool-name>.
>>>>>>
>>>>>> So proposing two approaches:
>>>>>> Patch 1) Introducing eal option --pkt-mempool=<pool-name>
>>>>>> Patch 2) Introducing ethdev API called _get_preferred_pool(), where PMD driver
>>>>>> gets a chance to advertise their pool capability to the application. And based
>>>>>> on that hint- application creates pools for that driver.  
>>> If the system is having more than one heterogeneous ethernet device with
>>> different mempool, the application has to create different mempool for each
>>> of the ethernet device.
>>>
>>> However, let's take a case
>>> As system has a DPAA2 eth device, which only work with dpaa2 mempools.  
>> dpaa2 ethdev will return dpaa2 mempool as preferred handler.
>>
>>> System also detect a standard PCI NIC, which can work with any software
>>> mempool (e.g ring_mp_mc) or with dpaa2 mempool. Given the preference, PCI
>>> NIC will have preferred as software mempool.
>>> how the application will choose between these, if it want to create only one
>>> mempool?  
>> We need add some policy in common code to help application to choose
>> in case if application interested in creating in one pool for
>> heterogeneous cases. It is more of application problem, ethdev can
>> return the preferred handler, let application choose interested in one.
>> ethdev is depended on the specific mempool not any other object.
>>
>> We will provide option 1(eal argument based one) as one policy.More sophisticated
>> policies we need add in application.
>>
>>
>>> Or, how the scheme will work if the application want to create only one
>>> mempool?  
>> option 1 (eal argument based) or we need to change the application to
>> choose from available ethdev count and its preferred mempool handler.
> I also think the approach in this patchset is not that bad:
>
> - The first step is to allow the user to specify the mempool
>   dynamically (eal arg).
>
>   One thing I don't really like is to have a mempool-related argument
>   inside eal. It would be better if eal could provide a framework so
>   that each libraries (ex: mbuf, mempool) can register their argument
>   that could be changed through the command line or trough an API.
>
>   Without this, it introduces a sort of dependency between eal and
>   mempool, which I don't think is sane.

Yes, eal has no such framework for the non-eal library.

IIUC, then are you looking at something like below:
- All non-eal library to register their callback function with eal.
- EAL iterates through registered callbacks and calls them one by one.
- EAL don't do the parsing and those non-eal libs do the parsing.
- EAL passes char *string arg as input to those registered callback function.
- It is up to those callback function to parse and find out i/p arg is correct
or incorrect.
- Having said that, then in the mempool case; We need to add new API to list 
the number of supported mempool handles(by name) and then compare/match 
i/p string with mempool handle(byname).

Are you referring to such framework? did I catch everything alright?

> - The second step is to be able to ask to the eth devices which
>   mempool they prefer. If there is only one kind of port, it's
>   quite easy.
>
>   As suggested, more complexity could go in the application if
>   required, or some helpers could be provided in the future.
>
>
> I'm sending some comments as replies to the patches.
>
If above eal framework approach is meeting your expectation then [1/4] need rework?
Or you want to keep [1/4] patch and I'll send v2 patch incorporating
your inline review comment, which one you prefer?


More information about the dev mailing list