From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0059.outbound.protection.outlook.com [157.56.112.59]) by dpdk.org (Postfix) with ESMTP id 728B58059 for ; Fri, 12 Dec 2014 09:31:17 +0100 (CET) Received: from zhigangTHINK (124.207.145.166) by AM3PR02MB0584.eurprd02.prod.outlook.com (10.242.253.142) with Microsoft SMTP Server (TLS) id 15.1.31.17; Fri, 12 Dec 2014 08:31:08 +0000 From: Tony Lu To: 'Neil Horman' References: <1418029178-25162-1-git-send-email-zlu@ezchip.com> <1418029178-25162-13-git-send-email-zlu@ezchip.com> <20141209140700.GB28871@hmsreliant.think-freely.org> In-Reply-To: <20141209140700.GB28871@hmsreliant.think-freely.org> Date: Fri, 12 Dec 2014 16:30:27 +0800 Message-ID: <003a01d015e5$ece132a0$c6a397e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdATuX4lmrpDzVHWQdyGMHGH3NPkawCKrBWA Content-Language: zh-cn X-Originating-IP: [124.207.145.166] X-ClientProxiedBy: BLUPR11CA0079.namprd11.prod.outlook.com (10.141.30.47) To AM3PR02MB0584.eurprd02.prod.outlook.com (10.242.253.142) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AM3PR02MB0584; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601003); SRVR:AM3PR02MB0584; X-Forefront-PRVS: 04238CD941 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(51704005)(13464003)(199003)(377454003)(24454002)(189002)(107046002)(61296003)(40100003)(120916001)(102836002)(64706001)(4396001)(105586002)(106356001)(50226001)(31966008)(99396003)(122386002)(46406003)(59696002)(47776003)(23726002)(97756001)(86362001)(20776003)(68736005)(33646002)(19580395003)(19580405001)(97736003)(96836002)(89996001)(33716001)(87976001)(46102003)(50986999)(21056001)(76176999)(66066001)(110136001)(14726001)(42186005)(92566001)(101416001)(50466002)(84116002)(2656002)(77156002)(62966003)(77096005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR02MB0584; H:zhigangTHINK; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AM3PR02MB0584; X-OriginatorOrg: ezchip.com Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 12/15] eal/tile: add mPIPE buffer stack mempool provider 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: Fri, 12 Dec 2014 08:31:17 -0000 >-----Original Message----- >From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Neil Horman >Sent: Tuesday, December 09, 2014 10:07 PM >To: Zhigang Lu >Cc: dev@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 >> Signed-off-by: Cyril Chemparathy >> --- >> 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.