From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0053.outbound.protection.outlook.com [157.56.110.53]) by dpdk.org (Postfix) with ESMTP id DCB145A8C for ; Tue, 31 May 2016 10:53:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YNzXZDAXHKJE/Jx6SwyAI/n6uaJJgQX+9IPxojs1asY=; b=bErFodfbyfHCJp4Pp9YA+euyqKhQ15Cs5kGCMXCqavFmrTSvadWVU38J0bJruBbgquQvVq7bMvi4lGE8Oa2MsmDDCjoddzGNIPCg2cfPAuEn8sQW/3m0OUJMI8CgTBsvitKdOqzxAflDhnfGXCbEfNpVQDyfzl9KjIFzycWgCHg= Authentication-Results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=caviumnetworks.com; Received: from localhost.localdomain (111.93.218.67) by BN3PR0701MB1720.namprd07.prod.outlook.com (10.163.39.19) with Microsoft SMTP Server (TLS) id 15.1.506.9; Tue, 31 May 2016 08:53:24 +0000 Date: Tue, 31 May 2016 14:23:03 +0530 From: Jerin Jacob To: "Hunt, David" CC: , , , Message-ID: <20160531085258.GA8030@localhost.localdomain> References: <1460642270-8803-1-git-send-email-olivier.matz@6wind.com> <1463665501-18325-1-git-send-email-david.hunt@intel.com> <1463665501-18325-2-git-send-email-david.hunt@intel.com> <20160524153509.GA11249@localhost.localdomain> <574818EA.7010806@intel.com> <20160527103311.GA13577@localhost.localdomain> <57485D4F.9020302@intel.com> <20160530094129.GA7963@localhost.localdomain> <574C239E.8070705@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <574C239E.8070705@intel.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-Originating-IP: [111.93.218.67] X-ClientProxiedBy: BM1PR01CA0018.INDPRD01.PROD.OUTLOOK.COM (10.163.198.153) To BN3PR0701MB1720.namprd07.prod.outlook.com (10.163.39.19) X-MS-Office365-Filtering-Correlation-Id: bf2e65e3-a93d-47a2-b67c-08d3893107b6 X-Microsoft-Exchange-Diagnostics: 1; BN3PR0701MB1720; 2:67C1EUMdhr1QK82gPgBkSdHkZmBc3DxUfoyGwlLDBNgTipnt0hTTc07WJX4w1V1/fn1XltjSOAqP9sEriRvx2jHMtu2IjWl0oIHHD4xQG9O2MuDVJNb9L4WaW9SHbATKapZ23ClGr922cvT+j2BAevMR+tCNlc4VTRKmebi52y6PZAlWywcEGG6T2uoi0So9; 3:CiWidWPqw0ui0DPuV1+xtUlPhRGP3vQbQx5LUhpdzotBlkjoOhaH7tQUWtEgTRaGYdE3RajBq8ZMhtOuEumcuPBQR/HbBSXnYfH9NL54lJPtXw2NebThJTi8DpuWPxJb X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0701MB1720; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0701MB1720; 25:Px+6TtoeIugAYSRmEkNpSG45ok6tfjiPKSUoOHksrUmZVxU5DO7Bm1hRbQKL03+acYFxE5sbAuPGX8asZurNM0aKBPFNMla0SaxnRiBWemNPl+0nbvVWuNmNwQ6Vkxns6OzAXaDRCLkQDlvgal4CuZl6P4H/a1OWgGe6uMW2ae7PzSlguiwFtpuaa9ASoI5Gy7In2lwp4hKFhJQrCRqXyE5HTc+leBxl71KdCLlen9L2UG8+vuoD3HFdxHGu0ngTRaGSjvby5wIJPsfVsLzoCvENJe39GjRB36sw9c7kLFT5Pn3rJ0Cl2BTmGDSSSn9qFFqK6i2OeLCezTSKGxwTbxbpj+nr5GT1lIepVaMvjzRqG9clj0aW0kC/l3wOk2v4POStP3ytC9Uageq83sva7pHEmCu+y+QcrpSnmFiOOAxLbQqt2zKPSb/IbzXX2tY8tmPUKhWAOZxcQ6yxtvgNsX7eToKIeN8CJHEUHrPyKKbdoKkXhxS93RAscWsIsEszEaay/Uu5/vmfNyaZlHHk7nGqrp1taQfieaecu9F+lV09Po7ytZkBFwu5+MqDgVLw0azG13yWAk5Cyi4/kDWF9ok/03R3v4O3IdoUPymj92UYU9m/1z7SXuYfrXLHIL78BDpMd+n2K+HLQ16p+SSyaWUZ8HAx9W+1Cdoh/mD2MfXIPYXp8r2uzdG2ScFqchlvG79c4OT3S+eNQ2kE02RgKPV/BXpwnu78cvAHgHfszL4mAU2Z1eOIkPOVEisJcKN/ X-Microsoft-Exchange-Diagnostics: 1; BN3PR0701MB1720; 20:gPa2xKt12ibWvGzcEkrcRkoOFqBfLEWfJqGzRJAHSE6dNnAuFrF7qfpC93GTmw6k4B/cnhr01ONNOgv+h8w3xu6G/fEmn5CnYj6pRJ65QNOM7Pzio+6n4g+74VtuWig3yvVV51PqFLQRP7iV4h9yDLaG/Zwz/1MbS8PuHNPYJNgsqP7n2JmZpsDoRfzMta12PeyevxPJlwN7sdvloCEIj4SxZ7FOWYu3ZCNFifu/38XvyKlJyAInbAE1zJpkhfxeGLptp3Ygfpc1aHSsvNRyWEF4Ia35pRZc8j5qny180vhbSV8fQMg5HcNRWWJxplwssfpJK9or3drQMH3beIDrerRyLZipX9KdhnPbQR/7ktP6PQQnNWX1lZZpqoWIsNTjALfS85phPW7WfT0qyKKZ19dvQ+RXnd5OuDpOAjphbjYIlRqdvZvo7Sjze50puJIax8FEJoUXqIKWq2WH1A1NRL2VZ6WON/f0TLLBUt0XdiwWRX590DHOXw9iQDU+9w1UzM8YbSLjuMMiPV2qK8ceX7X0pB+Z3nJejThs+5i2DYAhxgZJOGCt22UKLHyzGoqUu7rxqxkepx1GYkK1TmKijnfl6aVfrGp2+KSmjusFSZ8= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(131327999870524); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BN3PR0701MB1720; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0701MB1720; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0701MB1720; 4:Pl/RiBIQ5g4lWLJ4m9k2VXHov1XFMnKYQCcRU1NdK5/2+D9ubMfS5MkDmWehX2pilFwDkTflOD9PciX2mVJl2GG9iB2SBEQUn7Si555auVB0AlmIjFq6MXCjPsPmEOLLTBQu5w7Pw1i5bM8+6VXXmIby9y30ogvks8T5T+6OdeR4Po6V+XhuE5957e1qOvSYIjzsZ3HUX3G1d+hPvBtQVM4U64YHw9fXgSSpoqmBcTxUnHt5KvEkSNprC+3CuArxvXM6mb+T547ry7EVzfNeHREmk94f0YWZMbVoL1o2gUWXIJD+d6gSgSpQD+miOikW3ghvHdF5g7w9ecfNFeGdOcRIbyrlh9vd69wVLKREaLTG7oEm+l004U6vNiZWENwlqpuc/8nRoy0fPAmo1R9M2dX7OlnAo3aGE6aDXKK6uwKqUHhqpuvyCaG5nXBDtk09A4Qi52ukMHBughwLBZdZCw== X-Forefront-PRVS: 095972DF2F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(6069001)(24454002)(76104003)(23726003)(586003)(110136002)(5009440100003)(3846002)(4001350100001)(6116002)(46406003)(1076002)(93886004)(19580395003)(33656002)(5004730100002)(83506001)(5008740100001)(2950100001)(50986999)(76176999)(77096005)(54356999)(66066001)(42186005)(61506002)(2906002)(97756001)(47776003)(50466002)(9686002)(92566002)(81166006)(8676002)(189998001)(4326007)(7099028); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0701MB1720; H:localhost.localdomain; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0701MB1720; 23:4nKHCTDRF5IP//ysWAv8/bnC/AEnvx/NSXP13km?= =?us-ascii?Q?T1BMbKtvdL/8mz5VnvSuZB+mgornMa+6VtE7eQCEeDxWc1KZkSlmKgFSjDLt?= =?us-ascii?Q?2e6MY1JhExu/BseI664SRYD6bjssVLgm/8jeHnqwku122TyyZWuPBGLYpPxP?= =?us-ascii?Q?X9r+8sopJGiqfdCxuTFG5/QSi4tWcZU+MXD8Km/hlh77EfmnBnrD48tMg4co?= =?us-ascii?Q?Hr914yisT8NxVH23X69KbyNPA2fEmngf2bo7uNMxQGmpRPBSyXrUKPGFcR4f?= =?us-ascii?Q?vTyThNaM4NKPVS03XXnOjwLGJCQbcNCHJlFfjeiwbwURWgZVcNutkH1CtODO?= =?us-ascii?Q?5QrWchhDqzvK40pYysqH31fTywEztl65FIa4LBFKmekGVMrZbyWroFrOdIZx?= =?us-ascii?Q?AVMVhrjk2oX/GZ+ioXevzyGnLcf/tXa5eCqUB5OP4tx3fgDQBW8WY/alLECq?= =?us-ascii?Q?wtCSKeJJQWO2N8D/B1Wec5fBAj65t076YmrjqXm9F2/Dt0SbVRV3pOFNSUil?= =?us-ascii?Q?aKMMd8Nj5mDpxQ8Ty3pRE5F/EtutNZj/GsWOgXRB2i14GiJ33DUS/xEHi5vk?= =?us-ascii?Q?pKatMr3d7QhkgPB/6JQichMSTgpJTixYv9QxqTiaepxreOOGzQXLLftQU4HQ?= =?us-ascii?Q?fcSMev8QBwgm1FegveZqFIVzw4QG59/bZ6XUqu9LkESLt3ggBXutxdtYRLcO?= =?us-ascii?Q?R88JWVhYsHI55E+t2swI8FAk+EeAFEqkmPbLVOGHCDOJMCiNAshZWN8ERBBl?= =?us-ascii?Q?ERabj9Qa2y7w/P36f7kS7NV+Wta4Ya8lRV26QQkANLA+j7lxSIh0WqEFx1D4?= =?us-ascii?Q?fOkUMkwK1jjeoiUS89RhGaXwnMOSaR6JnZ4MR3ubtTJZL5ccS31In/bFObbc?= =?us-ascii?Q?9OxNXP6wVJoNpaS0TQaBjxtfjxWfJQdGhfCdSg2PxEz2e6LxsGVJwF1XADqp?= =?us-ascii?Q?UaGn7HA1dxOZ4MtCH8WTu+FY4MGyEdmrkwm7UGTWxRqLkStwng2sgBOIZLse?= =?us-ascii?Q?ugXdbOhyr7OkTAQigA2E7SzH4fhneukBc4+22mYBV3Bs9Zg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0701MB1720; 5:s8E7Bt7rDYkXIOUPdcb3yct1/LWnaf2X9H16+FOzTIUl8PAWw5ybt9uKbxCiRkQloMtZP2PN3X7zWch2i1dApH2dY/+fJHuLHFFvTirrNt3xVzhmNYkKvNoWUUZNp0X5qyjfYWg2Zh6j/dLXkQlwsQ==; 24:1/lcnUjAir4ChxuqDn/qn17WhjrXwOJ0TyyyRYY9Ktj4D80T2AEjkh25CZ2oxrZxHb9mMQD2dsxxELMQ96LOGXfRqqjSIgKUl2njHSW8G5Y=; 7:VfrMCNcEpXl/1qNaGWDebrd2rHWYkP4twrLJHCf62QgbtlOBER7pI6cH4CmSKZd635uknDqJFrRovayHENvS9MgsiWBXBOpwj9NJvasWRQcNFCmeGdObGuC1mn3MlAok+vvCuxxBbhd5c2C/skFBrDItokm0YsMqYprcPAwxbVuhmiP/E8pL8w0Xv9oiYyjJ SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 May 2016 08:53:24.3937 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0701MB1720 Subject: Re: [dpdk-dev] [PATCH v5 1/3] mempool: support external handler 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: Tue, 31 May 2016 08:53:28 -0000 On Mon, May 30, 2016 at 12:27:26PM +0100, Hunt, David wrote: > > New mempool handlers will use rte_mempool_create_empty(), > rte_mempool_set_handler(), > then rte_mempool_populate_*(). These three functions are new to this > release, to no problem Having separate APIs for external pool-manager create is worrisome in application perspective. Is it possible to have rte_mempool_[xmem]_create for the both external and existing SW pool manager and make rte_mempool_create_empty and rte_mempool_populate_* internal functions. IMO, We can do that by selecting specific rte_mempool_set_handler() based on _flags_ encoding, something like below bit 0 - 16 // generic bits uses across all the pool managers bit 16 - 23 // pool handler specific flags bits bit 24 - 31 // to select the specific pool manager(Up to 256 different flavors of pool managers, For backward compatibility, make '0'(in 24-31) to select existing SW pool manager. and applications can choose the handlers by selecting the flag in rte_mempool_[xmem]_create, That way it will be easy in testpmd or any other applications to choose the pool handler from command line etc in future. and we can remove "mbuf: get default mempool handler from configuration" change-set OR just add if RTE_MBUF_DEFAULT_MEMPOOL_HANDLER is defined then set the same with rte_mempool_set_handler in rte_mempool_[xmem]_create. What do you think? > to add a parameter to one of them for the config data. Also since we're > adding some new > elements to the mempool structure, how about we add a new pointer for a void > pointer to a > config data structure, as defined by the handler. > > So, new element in rte_mempool struct alongside the *pool > void *pool; > void *pool_config; > > Then add a param to the rte_mempool_set_handler function: > int > rte_mempool_set_handler(struct rte_mempool *mp, const char *name, void > *pool_config) IMO, Maybe we need to have _set_ and _get_.So I think we can have two separate callback in external pool-manger for that if required. IMO, For now, We can live with pool manager specific 8 bits(bit 16 -23) for the configuration as mentioned above and add the new callbacks for set and get when required? > > 2) IMO, It is better to change void *pool in struct rte_mempool to > > anonymous union type, something like below, so that mempool > > implementation can choose the best type. > > union { > > void *pool; > > uint64_t val; > > } > > Could we do this by using the union for the *pool_config suggested above, > would that give > you what you need? It would be an extra overhead for external pool manager to _alloc_ memory and store the allocated pointer in mempool struct(as *pool) and use pool for pointing other data structures as some implementation need only limited bytes to store the external pool manager specific context. In order to fix this problem, We may classify fast path and slow path elements in struct rte_mempool and move all fast path elements in first cache line and create an empty opaque space in the remaining bytes in the cache line so that if the external pool manager needs only limited space then it is not required to allocate the separate memory to save the per core cache in fast-path something like below, union { void *pool; uint64_t val; uint8_t extra_mem[16] // available free bytes in fast path cache line } Other points, 1) Is it possible to remove unused is_mp in __mempool_put_bulk function as it is just a internal function. 2) Considering "get" and "put" are the fast-path callbacks for pool-manger, Is it possible to avoid the extra overhead of the following _load_ and additional cache line on each call, rte_mempool_handler_table.handler[handler_idx] I understand it is for multiprocess support but I am thing can we introduce something like ethernet API support for multiprocess and resolve "put" and "get" functions pointer on init and store in struct mempool. Some thinking like file: drivers/net/ixgbe/ixgbe_ethdev.c search for if (rte_eal_process_type() != RTE_PROC_PRIMARY) { Jerin