On 3/24/2017 4:31 PM, Olivier Matz wrote: > Hi Ferruh, > > On Fri, 24 Mar 2017 15:59:50 +0000, Ferruh Yigit <ferruh.yi...@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.agra...@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 >
