[dpdk-dev] [PATCH 17/32] net/dpaa2: dpbp based mempool hw offload driver

[Jerin Jacob]

On Thu, Dec 15, 2016 at 12:07:51PM +0530, Shreyansh Jain wrote:
> On Thursday 15 December 2016 11:39 AM, Jerin Jacob wrote:
> > On Sun, Dec 04, 2016 at 11:47:12PM +0530, Hemant Agrawal wrote:
> > > DPBP represent a buffer pool instance in DPAA2-QBMAN
> > > HW accelerator.
> > > 
> > > All buffers needs to be programmed in the HW accelerator.
> > > 
> > > Signed-off-by: Hemant Agrawal <hemant.agrawal at nxp.com>
> > > ---
> > >  config/defconfig_arm64-dpaa2-linuxapp-gcc |   5 +
> > >  drivers/net/dpaa2/Makefile                |   2 +
> > >  drivers/net/dpaa2/base/dpaa2_hw_dpbp.c    | 366 ++++++++++++++++++++++++++++++
> > >  drivers/net/dpaa2/base/dpaa2_hw_dpbp.h    | 101 +++++++++
> > >  drivers/net/dpaa2/base/dpaa2_hw_pvt.h     |   7 +
> > 
> > 
> > How about moving the external mempool driver to RTE_SDK/driver/pool.
> > We are planning to push our external mempool driver to driver/pool.
> 
> I really like the idea of this separation:
> 
> So,
> ..drivers/net/<all PMDs>
> ..drivers/crypto/<all crypto PMDs>
> ..drivers/bus/<all bus handlers/drivers>
> ..drivers/pool/<all Pool handlers/drivers>
> 
> only concern I see for now is resolving dependency of symbols across this
> structure. for example, DPAA2 Pool would be dependent on some DPAA2 specific
> objects - which then are again used in crypto/ and net/.
> 
> It is possible to have drivers/common (which DPAA2 PMD patchset is already
> doing). How are you doing that?

Same approach. driver/common/octeontx directory for common octeontx driver code