On Fri, 24 Mar 2017 16:38:04 +0000, Ferruh Yigit <ferruh.yi...@intel.com> wrote: > 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.
Understood. Thanks. > > 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 > > >
