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.agra...@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
