From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0060.outbound.protection.outlook.com [157.56.112.60]) by dpdk.org (Postfix) with ESMTP id 3FEA12B85 for ; Fri, 10 Jun 2016 13:29:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=e3FfaCoD5t0Vr6Mix+x3dLN0VcWq9jaj7Cny80aao/c=; b=E47MVkPE+Ul8DKL36kmQTYEj11RJ6e4CR9txTisy4LL0QmJ3Ubaah9i45nSJpApdUFbQVOpmu1zsVYMibZVcMFo6tGa8mgo0vfLzxKKKib8fdJ00t1uwRsYrp6CQgOxQmlu/3SnpRFVN2pE85qiMbmuHPPSKySto/BFW5aVz6M0= Received: from DB5PR0401MB2054.eurprd04.prod.outlook.com (10.166.11.137) by DB5PR0401MB2053.eurprd04.prod.outlook.com (10.166.11.136) with Microsoft SMTP Server (TLS) id 15.1.517.8; Fri, 10 Jun 2016 11:29:37 +0000 Received: from DB5PR0401MB2054.eurprd04.prod.outlook.com ([10.166.11.137]) by DB5PR0401MB2054.eurprd04.prod.outlook.com ([10.166.11.137]) with mapi id 15.01.0517.005; Fri, 10 Jun 2016 11:29:37 +0000 From: Shreyansh Jain To: "Hunt, David" CC: "dev@dpdk.org" , "jerin.jacob@caviumnetworks.com" , Olivier Matz , "Jan Viktorin" Thread-Topic: [dpdk-dev] [PATCH v8 1/3] mempool: support external mempool operations Thread-Index: AQHRwJ6WYtTJj5Q9pk+CUYpxLcIab5/fWYJQgAGK+ACAADqLAIABM3UAgAAi5QCAAB2xAA== Date: Fri, 10 Jun 2016 11:29:32 +0000 Deferred-Delivery: Fri, 10 Jun 2016 11:29:24 +0000 Message-ID: References: <1464874043-67467-1-git-send-email-david.hunt@intel.com> <1464965906-108927-1-git-send-email-david.hunt@intel.com> <1464965906-108927-2-git-send-email-david.hunt@intel.com> <5756931C.70805@intel.com> <57593962.6010802@intel.com> <20160609150918.502322c8@pcviktorin.fit.vutbr.cz> <575A6C68.3090007@6wind.com> <575A89AE.4070709@intel.com> In-Reply-To: <575A89AE.4070709@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=shreyansh.jain@nxp.com; x-originating-ip: [192.88.169.1] x-ms-office365-filtering-correlation-id: 5f83c010-25a3-4de6-5574-08d39122813f x-microsoft-exchange-diagnostics: 1; DB5PR0401MB2053; 6:FNKbibMTjBET8WFLuDg22TBspWHfQ2Z2x3HcjGGQsVyaUmXdTPtZD+IJLv/hkbzUf0b6jET2b07qNlGJcI2nmVSS+lkcRHpw5Ji0JVndvCvvGrRE8n6dS3/XMCSBatd7DrAgeRkCV6WHNIMFH93LzomqJLPJSRTrVkvR1Zu8wmZJhcUZ29N40yQSEaeTvaJUUqQOM8hsuehLvbhZBH1vh3L++VfiGv1tpvCyMZsZBok29J75Q5uLeZnKQBjIh3KsuFw9Ye8sJHcNagUT0JT3d9eLM6vsWgH/pEQqBbYA2PSrQYHGRJjcVebn8B5rZGpc; 5:PGsvz48Ik7sQxAH52dCQmg9txtEGUmWJPoDIOca1Ty1Yp/8LM2gC39GNvesvezRyInDqlYWdBGcvREm9uy1ALtjdu2vmVH9biDMpyQv3fDHouSV2slns+5agJXJulWFS5rKxoscd0n/CZRKheCGD5Q==; 24:LmTSV4I6DVFtnoPayfAq9hN482+XteDlbC+qkPxxdDJJRmYsxvau1U8lDNs6BoYLakgmdIaKXU8xu7afk8+NM2CNN9y7Hs3NYHdApJGztss=; 7:FPKbaSxIzGbM4/1bWoYWGNCAsh7zeaFltjk3fXjueqNtXE44a2j+ebnSwoMLTtXPgBBzhlQklckF0im/NWANx0hS4JtXKWvNfJOM8Nb5qcAiW/JXLgF9QICsWMkVNrB/cK3YB6Sbr44UFpoVEzpQjaaUyfxjWr+68dBddE9BgFJKKWrwefdHaYqOAiONyu859zyMywkb+JfF7s/NbhJtdEBvC2U5/96hVViLCchk+8U= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR0401MB2053; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(185117386973197)(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:DB5PR0401MB2053; BCL:0; PCL:0; RULEID:; SRVR:DB5PR0401MB2053; x-forefront-prvs: 096943F07A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(189002)(51444003)(199003)(13464003)(53754006)(377454003)(101416001)(81156014)(9686002)(66066001)(8676002)(81166006)(5002640100001)(105586002)(76176999)(97736004)(4326007)(92566002)(2950100001)(586003)(77096005)(2900100001)(5003600100002)(19580405001)(68736007)(3846002)(102836003)(3660700001)(8936002)(19580395003)(6116002)(3280700002)(2906002)(76576001)(93886004)(74316001)(86362001)(122556002)(110136002)(87936001)(33656002)(11100500001)(189998001)(10400500002)(5008740100001)(106116001)(5004730100002)(54356999)(50986999)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR0401MB2053; H:DB5PR0401MB2054.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2016 11:29:37.0517 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR0401MB2053 Subject: Re: [dpdk-dev] [PATCH v8 1/3] mempool: support external mempool operations 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, 10 Jun 2016 11:29:39 -0000 Hi David, > -----Original Message----- > From: Hunt, David [mailto:david.hunt@intel.com] > Sent: Friday, June 10, 2016 3:05 PM > To: Olivier Matz ; Jan Viktorin > > Cc: Shreyansh Jain ; dev@dpdk.org; > jerin.jacob@caviumnetworks.com > Subject: Re: [dpdk-dev] [PATCH v8 1/3] mempool: support external mempool > operations >=20 > Hi all, >=20 > On 10/6/2016 8:29 AM, Olivier Matz wrote: > > Hi, > > [...snip...] > > > > > >> So, the old applications can stay as they are (OK, with a possible > >> new flag MEMPOOL_F_PKT_ALLOC) and the new one can do the same but you > >> have to set the ops explicitly. > >> > >> The more different ways of using those APIs we have, the greater hell > >> we have to maintain. > > I'm really not in favor of a MEMPOOL_F_PKT_ALLOC flag in mempool api. >=20 > I would tend to agree, even though yesterday I proposed making that > change. However, > thinking about it some more, I'm not totally happy with the > MEMPOOL_F_PKT_ALLOC addition. It adds yet another method of creating a > mempool, > and I think that may introduce some confusion with some developers. >=20 > I also like the suggestion of rte_pktmbuf_pool_create_(..., > name) suggested > above, I was thinking the same myself last night, and I would prefer > that rather than adding the > MEMPOOL_F_PKT_ALLOC flag. Developers can add that function into their > apps as a wrapper > to rte_mempool_create_empty->rte_mempool_set_ops_byname should the need > to have > more than one pktmbuf allocator. Otherwise they can use the one that > makes use of the > RTE_MBUF_DEFAULT_MEMPOOL_OPS config setting. +1 >=20 >=20 > > I think David's patch is already a good step forward. Let's do it > > step by step. Next step is maybe to update some applications (at least > > testpmd) to select a new pool handler dynamically. > > > > Regards, > > Olivier Thanks. - Shreyansh