From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0069.outbound.protection.outlook.com [65.55.169.69]) by dpdk.org (Postfix) with ESMTP id 0B3732BA6 for ; Fri, 10 Jun 2016 13:13:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BuS+DyGFAHI5IiUPlGMavYsXWMfQz0mu54EpGAK2fl8=; b=acpfOcDARu5jD97D23PHS1vJ5U3S7k0bxI1VI4Qyj/vHy9NzgaTyStKf/3pp65Zk3jXb2oGXAMlPla6k3hW6sRk75HlkxybZwQA0ZohVMM4aBJeUxFanHEeDBv9ZB//X0wXxvBa8YaTnhQ85Pcrak5WcPb2VhQlerHXxsf5R6Bc= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.Jacob@cavium.com; Received: from localhost.localdomain (111.92.121.228) by CY1PR0701MB1728.namprd07.prod.outlook.com (10.163.21.142) with Microsoft SMTP Server (TLS) id 15.1.511.8; Fri, 10 Jun 2016 11:13:29 +0000 Date: Fri, 10 Jun 2016 16:43:10 +0530 From: Jerin Jacob To: Olivier Matz CC: Jan Viktorin , "Hunt, David" , Shreyansh Jain , "dev@dpdk.org" Message-ID: <20160610111301.GA3743@localhost.localdomain> 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> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <575A6C68.3090007@6wind.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-Originating-IP: [111.92.121.228] X-ClientProxiedBy: MAXPR01CA0039.INDPRD01.PROD.OUTLOOK.COM (10.164.146.139) To CY1PR0701MB1728.namprd07.prod.outlook.com (10.163.21.142) X-MS-Office365-Filtering-Correlation-Id: 9048589b-40da-48d3-dcd2-08d3912041bb X-Microsoft-Exchange-Diagnostics: 1; CY1PR0701MB1728; 2:ncunCU1DPiZD8XHOHc58PNXbg0IiSWoAtyAsn+OAohVxnTFOL0qac5wamEdfKrJnV1t8yGQE5HQOQZWXK8Tb1T1qbbixvjCijNh67vpNhPwtrgjV5e3gsSexxXjTIjDS8e2/5mQaoe48kUJKllpHbjaSQQH9AZZYz/b/KV/zHEg79FSI4cxP2RngfgAIRmUT; 3:PS4Vk4Gpru6UAF5MyhjqojrQ7qgTpJMFdliuCHoIXQC33SQvIZBtp71zz0b+pk1Hks6RmcsFDh6AKZoXgl6aH0GYtM5GQszeYtnCCrDkyWaimbQCfa5wFx1SX+WljCoK; 25:2I+tplgKQ8XEQ6OHMQcsGWBcUhnkXNKT0rAcJHK0py99e6v0SuIfYwa7MNAQ2px+LQ+Ds+akYMSgTrT4b9APn8lSDJ9cVcNMyuFwRy8H5U4OZTlZFfmLqmuXsRDGvd6dAPMUZBXdGlez8WDDh3+YDP+A7gMH5CJJMtKDjy4Pd9/TQz498shPyPC5ZyEnhUcCuUmPvb+KebZSP/lDkrJzXtAxh/Ax1uae0FJ5OP9DFm6VKi31pCFaBLinHA7mDblJJY4+t3wAdccHQM/LDgR46BZJfoafy45eOuR2qIGAeQkYfdNjNd4U9/QcLGqPyoglDj/c6GXRcFZZZFVHJVBrKT/XAvP0ann4FExhQeGuRSeAIyAgBC5lH17r1aWE+vydv2XqYr2w8sPT9DF2I7ZoaXwelGCQlrfi0r7QsCwaDsI= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1728; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0701MB1728; 20:raxKlWMBsrf1fO/inFnBorvEGwK5T+NrRRsOCN8AaMUnDjIGhGdUDxsb1IJBIViMsEW00ek/gjtEn6pHS1DnnbYp6G6Q77S7FBg62EeBKU8Zf26OLe4mNdM+XbGidgn3Y3OgIVbM94XaDyFY19q7RgMi8Oct/OLw6dwaHTghjS8EHhlbgSArl3n6gcHuyNUhE7/r0SUi8vGjIoYW8NK57XlYWZrIIZZj88A4h/4r45sy0LI/wIqPJ9mXHJFdSBJolOdVJZiebMgcz+kdhIZGcvcWuQC5IHgLTJWwHNDDlBaIZ4fER5GHkJGv6RzR3yb/F6h+xmae0akBRnsyNAMDwwENavpPFasrN53VScFIq7fTUka4zyav2JSX9asdg5c063iSRDvTuUezqCrptsLoejlIcsa4JmaY3FM7j9N7E981fYVbkY4kfsaqWrCJTYc4pmstjrtHrMAO7yWc2ZVGDKHVUltn+NaoE6cNVhfQn/imQexayuFXSdM6SB6BFRye0G1LrwNzjF8OHPoGFVSJqvz2E9Di4f9fGW84QLpnRmdSTy5EcWnFzwelYyfeO9ZPTdMdwz6L/Go+eoykEIbbfrE2n0LNbah6D7o/WH4skgA= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:CY1PR0701MB1728; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1728; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0701MB1728; 4:qY2+QjfOH8XlwLcQU83AQvJudWKwaXWEMb+WEo8Z6cbMcX3bmpinFiozxEBq6j3yzlSwpiNZQPCNl3r4Kt0r4l8mh3fzN5wC5s2cSXerrqqBywIuwiK0Jbu/b3ZwrMI5BFbWEOfkiO88QHsS1CT+w7ymECQjxNZZeyZA3BQcTctf01twT6+US5fFcRwQZBvm7wnbfZJaFz0B2vKtnfryV3Tf/S4JmwsjHlLWGmiLcQaXkcZGxImuzSZ9tgtRDTT+KNeERtd7ueBdXWUnJhCAtR7EPMRggUx67dsDpQHdzGakZqONBDXiHBrmQMjIM+xNAL9V8ySAlfWqiSBuau4PHZDvUsVkUIRKo8oWXiY5uqaVk0IxMRF+3hSWLnnqtWk3CDw4pNki/voXmA0IHC5BSkVnbsue1RwSrnhc0tzQl2g= X-Forefront-PRVS: 096943F07A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(6069001)(189002)(377454003)(24454002)(199003)(2950100001)(1076002)(97756001)(42186005)(23726003)(9686002)(8666004)(66066001)(50466002)(4001350100001)(61506002)(2906002)(6116002)(5004730100002)(68736007)(81156014)(81166006)(8676002)(4326007)(47776003)(83506001)(3846002)(46406003)(106356001)(586003)(93886004)(105586002)(77096005)(101416001)(110136002)(92566002)(5008740100001)(5009440100003)(97736004)(33656002)(189998001)(50986999)(54356999)(76176999)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0701MB1728; H:localhost.localdomain; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0701MB1728; 23:wkEXYoi2mjWzEPglcZa+kh6A/609KfLFtU9NVkq?= =?us-ascii?Q?Ic2iUxvUbdkH3HBrWK643J+huiXrPy7rOT2McZKmZZc3sIV8iyl3NBWQc+Hu?= =?us-ascii?Q?/jRHAqtZs5TzAwhI8A7yWYEyfMJq9IJBrtUaTvke/Xsgoav/GJO3iZc9Z+WT?= =?us-ascii?Q?FMh1PTfrhnhkRTLmp6PPdoP83JUi5NNVCdFS01S2qDyUA35N/gMVBwLKYOJg?= =?us-ascii?Q?F3nxMeUT+4ogDNp9C96FwGEAdqlxL+bOdM550tkBDVMvhiUYt1KWsGJMEAeb?= =?us-ascii?Q?LrVh+1NLfLL5Ewt1hpzNI+2/9LyvCcUBd6VKRaaXF6O3jNMN5PHGl4u+Bgig?= =?us-ascii?Q?TedZ2CGv1UyNBEI46PrPzcSfQkJQtxvdQbDLiitH21j1CcTN+41/20GgwmIu?= =?us-ascii?Q?iLzErz5OlWlvjw/I5RBhI2YeJZYN2/7kFHPLze8n9zq1CqOqHFkk3rjA45GV?= =?us-ascii?Q?Z3sc06zdF13rcTify+plguFsc0QExs8tjfJTJGs9Wktb9v0Viuam/wuuYAGS?= =?us-ascii?Q?l+LbqCQkYf0oOnoFToSFezpxRttjj1tD+nVMGYb50YN8XL8P+/ErjHZxLSiL?= =?us-ascii?Q?YdyngVIna5l2E0AVFjR9DTU2RgxSbdqKipFF34eZAow5wDPjSZWmvsYqDkqK?= =?us-ascii?Q?QfuQ75QPv1nnHzDeUdz/c+mkAS2GjfE4ogbCB/KBO0TBprhYrUp7fM8arBrq?= =?us-ascii?Q?YHVF5WdfE+txyHShEQMKE0vKsq/K4VzNqI6Yl8lT0jTQr3EOL+LFOSimVkH6?= =?us-ascii?Q?Y4Cz5TqibzB5AbsnI4DyJDTfjpWS/vQV4MoO3mjd9RDdyt/j5T8VIyer1+9R?= =?us-ascii?Q?ZU7bWk+bc6tUCpZEYJ2bwP7J+xoSo917Shq3++jesrwjNHufFNTVCEq5rCr1?= =?us-ascii?Q?1sR/ETeofN/zET+9/5D2j5Pe52TLoD+IYHj6FgU2tTJSTfmw99TmhxRDaDOK?= =?us-ascii?Q?nVM+cqZkZWccjtafxOphkO+tcxIhCgyTVA3WPhg7RZFF8DEoUrQGkRwUqGdC?= =?us-ascii?Q?W+2sQtL66yBkrXZPt2TLgov1JLD1/vjGqqwwa7HO8/QBkFPSfOEX4hlVZUu2?= =?us-ascii?Q?Z9j97cZm5yKIHSeV9R0J5bK+5I5iE1R1+Xm9Gf08+gnsjBgfzKORDiNmFl0y?= =?us-ascii?Q?dJcKY/GEStGNrgpWifK/z94a8OHD+zQVVUshTfwND+EJmnr2XHJX4q1TaBRJ?= =?us-ascii?Q?Kb5p99aHagt1Qb98QOuuf+BfBtXo6iPApNC0y?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0701MB1728; 5:GTfIWrclJv4fJxcQ7SCM4Vq8ywIUCt+PADfR+86Lk0SiuIHSsbFPkak2bVVUsZgMPgig/lQWV6j6q6qubJYs84l7+Czz7EHGE4b9pHLmtqHeUyaaY6Do9F4F6WbkjJ0Qj34IvfnQl4w1RTWdXrx07g==; 24:FcNwAiR5t9NK96Uk52eCLAX1hQq05zI9XsBpYnlv35YFMYv/VtayqKF/Y60etMTpOiW4tDEJ8tsBXWX4vQ40ZMlKRpoe5bMo0pp6kUtj88E=; 7:9rJl709b2PZSGkEejfrnh/w0YpvFT9txQ1GOVo5Gq0VobfVyGGFVrT9HEvsIgmNu6MpRPWunb9sBYkE2CabUHMNhp2+7V/hLX1/lKIcbrzd5t58z86s/tqww1ATFNzrFteyfC7a0q9NdnCana7eAscfk41Oqn9GMfPQ1ol7eeRY0FcmyNy744MqJVscbdMXP51q4Tr2L5lamVAHbo1txK3XMnMEFu0Sbkdqyw66lUb0= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jun 2016 11:13:29.3556 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0701MB1728 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:13:34 -0000 On Fri, Jun 10, 2016 at 09:29:44AM +0200, Olivier Matz wrote: > Hi, > > On 06/09/2016 03:09 PM, Jan Viktorin wrote: > >>> My suggestion is to have an additional flag, > >>> 'MEMPOOL_F_PKT_ALLOC', which, if specified, would: > >>> > >>> ... #define MEMPOOL_F_SC_GET 0x0008 #define > >>> MEMPOOL_F_PKT_ALLOC 0x0010 ... > >>> > >>> in rte_mempool_create_empty: ... after checking the other > >>> MEMPOOL_F_* flags... > >>> > >>> if (flags & MEMPOOL_F_PKT_ALLOC) rte_mempool_set_ops_byname(mp, > >>> RTE_MBUF_DEFAULT_MEMPOOL_OPS) > >>> > >>> And removing the redundant call to rte_mempool_set_ops_byname() > >>> in rte_pktmbuf_create_pool(). > >>> > >>> Thereafter, rte_pktmbuf_pool_create can be changed to: > >>> > >>> ... mp = rte_mempool_create_empty(name, n, elt_size, cache_size, > >>> - sizeof(struct rte_pktmbuf_pool_private), socket_id, 0); > >>> + sizeof(struct rte_pktmbuf_pool_private), socket_id, + > >>> MEMPOOL_F_PKT_ALLOC); if (mp == NULL) return NULL; > >> > >> Yes, this would simplify somewhat the creation of a pktmbuf pool, > >> in that it replaces the rte_mempool_set_ops_byname with a flag bit. > >> However, I'm not sure we want to introduce a third method of > >> creating a mempool to the developers. If we introduced this, we > >> would then have: 1. rte_pktmbuf_pool_create() 2. > >> rte_mempool_create_empty() with MEMPOOL_F_PKT_ALLOC set (which > >> would use the configured custom handler) 3. > >> rte_mempool_create_empty() with MEMPOOL_F_PKT_ALLOC __not__ set > >> followed by a call to rte_mempool_set_ops_byname() (would allow > >> several different custom handlers to be used in one application > >> > >> Does anyone else have an opinion on this? Oliver, Jerin, Jan? > > > > I am quite careful about this topic as I don't feel to be very > > involved in all the use cases. My opinion is that the _new API_ > > should be able to cover all cases and the _old API_ should be > > backwards compatible, however, built on top of the _new API_. > > > > I.e. I think, the flags MEMPOOL_F_SP_PUT, MEMPOOL_F_SC_GET (relicts > > of the old API) should be accepted by the old API ONLY. The > > rte_mempool_create_empty should not process them. > > The rte_mempool_create_empty() function already processes these flags > (SC_GET, SP_PUT) as of today. > > > Similarly for a potential MEMPOOL_F_PKT_ALLOC, I would not polute the > > rte_mempool_create_empty by this anymore. > > +1 > > I think we should stop adding flags. Flags are prefered for independent > features. Here, what would be the behavior with MEMPOOL_F_PKT_ALLOC + > MEMPOOL_F_SP_PUT? +1 MEMPOOL_F_PKT_ALLOC introduced only for legacy application to make it work with external pool manager. If we are not taking that path(and expects applications to change) then IMO we can we have proper mempool create API to accommodate the external pool and deprecate rte_mempool_create/rte_mempool_xmem_create like, 1) Remove 10 to 15 arguments pool create and make it as structure(more forward looking) 2) Remove flags 3) Have the same API for external and internal mempool create and differentiate through handler through "name". NULL can be default mempool handler(MPMC) > > Another reason to not add this flag is the rte_mempool library > should not be aware of mbufs. The mbuf pools rely on mempools, but > not the contrary. >