On Fri, 24 Mar 2017 16:38:04 +0000, Ferruh Yigit [off-list ref] wrote:

On 3/24/2017 4:31 PM, Olivier Matz wrote:

quoted

Hi Ferruh,

On Fri, 24 Mar 2017 15:59:50 +0000, Ferruh Yigit [off-list ref] wrote:  

quoted

On 3/24/2017 2:57 PM, Ferruh Yigit wrote:  

quoted

On 3/17/2017 12:47 PM, Hemant Agrawal wrote:    

quoted

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 <redacted>    

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.

Understood. Thanks.

Thanks,
ferruh

quoted

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