Re: [dpdk-dev] [PATCH 11/15] eal/tile: add EAL support for global mPIPE initialization

[Cyril Chemparathy <cchemparathy@ezchip.com>]

Hi Neil,


On 12/8/2014 12:03 PM, Neil Horman wrote:
> On Mon, Dec 08, 2014 at 04:59:34PM +0800, Zhigang Lu wrote:
>> The TileGx mPIPE hardware provides Ethernet connectivity,
>> packet classification, and packet load balancing services.
>>
>> Signed-off-by: Zhigang Lu <zlu@ezchip.com>
>> Signed-off-by: Cyril Chemparathy <cchemparathy@ezchip.com>
>> ---
>>   .../common/include/arch/tile/rte_mpipe.h           |  67 ++++++++++
>>   lib/librte_eal/linuxapp/eal/Makefile               |   3 +
>>   lib/librte_eal/linuxapp/eal/eal.c                  |   9 ++
>>   lib/librte_eal/linuxapp/eal/eal_mpipe_tile.c       | 147 +++++++++++++++++++++
>>   mk/rte.app.mk                                      |   4 +
>>   5 files changed, 230 insertions(+)
>>   create mode 100644 lib/librte_eal/common/include/arch/tile/rte_mpipe.h
>>   create mode 100644 lib/librte_eal/linuxapp/eal/eal_mpipe_tile.c
>>
> This seems like the wrong way to implement mpip access.  If you want to use it
> for networking access, you should create a pmd to talk to it.  If you just want
> raw gxio access, you already have a gxio library that applications can interface
> to.  Theres no need to create addtional DPDK api services just to wrap it up,
> especially given that those surfaces won't exist outside of the tile arch (i.e.
> this allows for the creation of very non-portable applications).

Thanks for the taking a look.

The mPIPE hardware block includes hardware managed buffer pools, which 
we've abstracted under the mempool interface in the very next patch in 
the series.  As a result of this mempool dependency, mPIPE needs to be 
globally initialized on TileGX architecture.

The alternative is to not include support for the hardware managed 
buffer pool, but that decision incurs a significant performance hit.

Thanks
-- Cyril.