>-----Original Message----- >From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman >Sent: Tuesday, December 09, 2014 10:07 PM >To: Zhigang Lu >Cc: dev at dpdk.org >Subject: Re: [dpdk-dev] [PATCH 12/15] eal/tile: add mPIPE buffer stack mempool >provider > >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?
Yes, the mempool we are using is very much tile-specific, as we want to use the mpipe hardware managed buffer pool to implement the mempool, which greatly improve the performance of mempool. As Cyril replied in a previous email: The alternative is to not include support for the hardware managed buffer pool, but that decision incurs a significant performance hit.
