[dpdk-dev] [PATCH v1] mempool/dpaa2: add DPAA2 hardware offloaded mempool

Ferruh Yigit ferruh.yigit at intel.com
Fri Mar 24 17:38:04 CET 2017


On 3/24/2017 4:31 PM, Olivier Matz wrote:
> Hi Ferruh,
> 
> On Fri, 24 Mar 2017 15:59:50 +0000, Ferruh Yigit <ferruh.yigit at intel.com> wrote:
>> On 3/24/2017 2:57 PM, Ferruh Yigit wrote:
>>> On 3/17/2017 12:47 PM, Hemant Agrawal wrote:  
>>>> DPAA2 Hardware Mempool handlers allow enqueue/dequeue from NXP's
>>>> QBMAN hardware block.
>>>> CONFIG_RTE_MBUF_DEFAULT_MEMPOOL_OPS is set to 'dpaa2', if the pool
>>>> is enabled.
>>>>
>>>> This memory pool currently supports packet mbuf type blocks only.
>>>>
>>>> Signed-off-by: Hemant Agrawal <hemant.agrawal at nxp.com>  
>>>
>>> Applied to dpdk-next-net/master, thanks.  
>>
>> Hi Olivier,
>>
>> I get this to next-net, since dpaa2 net driver depends this one.
>>
>> But were you planning any review on the code? Or is it good to go as it is?
> 
> Yes, but I'm afraid I won't be able to do it today.

OK, when you done your review, we can act according its result.

I just want to remind the dependency chain, dpaa2 net depends this
patch, and dpaa2 crypto depends net one.
An early integration from next-net required so that next-crypto can
finish its work before integration deadline.

Thanks,
ferruh

> 
> From high level, I'm still a little puzzled by the amount of references
> to mbuf in a mempool handler code, which should theorically handle any
> kind of objects.
> 
> Is it planned to support other kind of objects?
> Does this driver passes the mempool autotest?
> Can the user be aware of these limitations?
> 
> 
> Thanks,
> Olivier
> 



More information about the dev mailing list