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

[Olivier Matz]

On Fri, 24 Mar 2017 16:38:04 +0000, Ferruh Yigit <ferruh.yigit at 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.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.

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