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?


 drivers/net/dpaa2/dpaa2_vfio.c            |  13 +-
 6 files changed, 493 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/dpaa2/base/dpaa2_hw_dpbp.c
 create mode 100644 drivers/net/dpaa2/base/dpaa2_hw_dpbp.h



Reply via email to