From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id DE61F3F9 for ; Mon, 8 Dec 2014 21:04:03 +0100 (CET) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1Xy4X0-0004CP-55; Mon, 08 Dec 2014 15:03:54 -0500 Date: Mon, 8 Dec 2014 15:03:31 -0500 From: Neil Horman To: Zhigang Lu Message-ID: <20141208200331.GB4238@hmsreliant.think-freely.org> References: <1418029178-25162-1-git-send-email-zlu@ezchip.com> <1418029178-25162-12-git-send-email-zlu@ezchip.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1418029178-25162-12-git-send-email-zlu@ezchip.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: dev@dpdk.org, Cyril Chemparathy Subject: Re: [dpdk-dev] [PATCH 11/15] eal/tile: add EAL support for global mPIPE initialization X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 20:04:04 -0000 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 > Signed-off-by: Cyril Chemparathy > --- > .../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). NAK