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

[Neil Horman <nhorman@tuxdriver.com>]

On Mon, Dec 08, 2014 at 01:32:30PM -0800, Cyril Chemparathy wrote:
> 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.
> 
Ok, but you already have a mechanism to do that, in that the application can use
the gxio library to do the initialization itself, and you don't need to provide
additional wrapper calls that are arch specific in a common library.

> The alternative is to not include support for the hardware managed buffer
> pool, but that decision incurs a significant performance hit.
> 
No, there are plenty of alternatives to just not doing it.  In fact, you can
create a constructor to do this initialization work, and manage the instance
id's so that the user never has to see it

Neil

> Thanks
> -- Cyril.
>