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.ja...@caviumnetworks.com> wrote: >> -----Original Message----- >>> Date: Tue, 20 Jun 2017 16:07:17 +0530 >>> From: Hemant Agrawal <hemant.agra...@nxp.com> >>> To: Jerin Jacob <jerin.ja...@caviumnetworks.com> >>> CC: Santosh Shukla <santosh.shu...@caviumnetworks.com>, >>> olivier.m...@6wind.com, dev@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.agra...@nxp.com> >>>>> To: Santosh Shukla <santosh.shu...@caviumnetworks.com>, >>>>> olivier.m...@6wind.com, dev@dpdk.org >>>>> CC: jerin.ja...@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?
