[dpdk-dev] [PATCH 12/15] eal/tile: add mPIPE buffer stack mempool provider
Neil Horman
nhorman at tuxdriver.com
Tue Dec 9 15:07:00 CET 2014
On Mon, Dec 08, 2014 at 04:59:35PM +0800, Zhigang Lu wrote:
> TileGX: Modified mempool to allow for variable metadata.
> Signed-off-by: Zhigang Lu <zlu at ezchip.com>
> Signed-off-by: Cyril Chemparathy <cchemparathy at ezchip.com>
> ---
> app/test-pmd/mempool_anon.c | 2 +-
> app/test/Makefile | 6 +-
> app/test/test_mempool_tile.c | 217 ++++++++++++
> lib/Makefile | 5 +
> lib/librte_eal/linuxapp/eal/Makefile | 4 +
> lib/librte_mempool_tile/Makefile | 48 +++
> lib/librte_mempool_tile/rte_mempool.c | 381 ++++++++++++++++++++
> lib/librte_mempool_tile/rte_mempool.h | 634 ++++++++++++++++++++++++++++++++++
> 8 files changed, 1295 insertions(+), 2 deletions(-)
> create mode 100644 app/test/test_mempool_tile.c
> create mode 100644 lib/librte_mempool_tile/Makefile
> create mode 100644 lib/librte_mempool_tile/rte_mempool.c
> create mode 100644 lib/librte_mempool_tile/rte_mempool.h
>
NAK, this creates an alternate, parallel implementation of the mempool api, that
re-implements some aspects of the mempool api, but not others. This will make
for completely no-portable applications (both to and from the tile arch), and
create maintnence problems, in that features for mempool will need to be
implemented in multiple libraries.
I understand wanting to use mpipe, and thats perfectly fine, but creating
no-portable apis to do so isn't the right way to go. Instead, why not just
allow applications to use mpipe by initalizing it via the gxio library and
crating a mempool using the existing libraries' rte_mempool_xmem_create api
call, which allows for existing allocated memory space to be managed as a
mempool?
Neil
More information about the dev
mailing list