[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