From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0083.outbound.protection.outlook.com [157.56.110.83]) by dpdk.org (Postfix) with ESMTP id 6113BC718 for ; Fri, 29 Jan 2016 18:17:04 +0100 (CET) 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 (122.167.54.52) by BLUPR0701MB1714.namprd07.prod.outlook.com (10.163.85.140) with Microsoft SMTP Server (TLS) id 15.1.396.15; Fri, 29 Jan 2016 17:17:01 +0000 Date: Fri, 29 Jan 2016 22:46:39 +0530 From: Jerin Jacob To: "Hunt, David" Message-ID: <20160129171638.GA12595@localhost.localdomain> References: <1453829155-1366-1-git-send-email-david.hunt@intel.com> <20160128172631.GA11992@localhost.localdomain> <56AB6BD8.9000403@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <56AB6BD8.9000403@intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [122.167.54.52] X-ClientProxiedBy: MAXPR01CA0005.INDPRD01.PROD.OUTLOOK.COM (25.164.147.12) To BLUPR0701MB1714.namprd07.prod.outlook.com (25.163.85.140) X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 2:WDM/uPyuWZNp3hybZ6zHNY6sYqTIOJS+UWRtgYe83F6eMNSw03vTx646+ZzAxNJW6rZ13Ip/56gTiUU6fBOGWgpBX98SOu3PTVgA2HquU/cYeFO3z09swLthHRk3gUMBHCFMf54VLjJes4nmrT+08Q==; 3:cyDf9Mi48FKqg3GzKZ0qrnfcJCs8X7tJJFynGndiTWbcMFSc7EAM6kTNBpYXGyiU03LXLTfSFoKv/qvL0t88LP6e/7eSYXFZdu+QbCWa1+9tHeVFfFObgXctgnWBBlK8; 25:QZbNQmJr4Yr8/AzGAV2RA/9RhTgGiyImOyc+EFabOUY8G8AzUtKufgoNC8wfkIFyifzhvGVlllvJ6mumnCG8+qIqFSE9YXnPNUP8loy1IfXiPLiJ0Kd/dt2eglxi1bQyNfFEHcza9p04Tkby6H8IOAWIufc3S+GA1Q0+rlduw2C5Ks1ptR61Ktoi0ux95G20y+kgAtWitgYMN7VOFKBjKPzyjIwqFWhzUUGbj0m7ec6Z43xn7TWXI5/WBxVQvto+ X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0701MB1714; X-MS-Office365-Filtering-Correlation-Id: 73c5fdd2-9ed5-4b09-c678-08d328d00117 X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 20:rlK/ZvAukclw5gudRt0e1FZt0+J+8qVuxJ5m8H3W8g6+IsXYQt/jN971BWjTq9rwK3lb1FjuGWPVN6SLS+tW6o0O26djwLlEdRwSbD378c1EJ8kiLlsHpYihVyJlKjqowFztIBSkAwPB3vSqev8Mf8k6vjEDC0p5oOUwuT4wkCm8Xk/kLiOSru5mor9UotrxGYAcG+visIz+KA3RySFSFfGarSH69RwhxEgIBzu/IvBRMHsXVIlj/cZ5drQmvDlUYeayOLmkmTo9oEMzAnpmlZo0Ia6tI59D/2Mv8kF8KByhdTUx3pwhtnzI7hfVc3FCpOSOLkLkPonOx0m8G9cvOxvB2HVamE7yt5UeubB3Oab2jgz5FsqKl9xiFCTCNhTVpNU8796ZMBY0yrWaQ+RsuR1HF9kAFai9nv7+1+1Thx/nXQD1+BIgukGvU0Emhir3+iFxNe8OsQ+5FX22y7Gkjz9VDkq53AxM38pc5F8qz9ypDN9d+n0sASbleSh7TAfkTKLTMj88aaj0xhnq+fq01/6gQads/ZyasoTLP9py73EtITAOIWh3YJFNMT7NgImhpNnj/rzqhL3901d7v1jdkO4/MIdvkX6pBihvupCJTaI= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BLUPR0701MB1714; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0701MB1714; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 4:btQNz0dLvl5kcLT7hhdTQkJmNlVGrUkOiIGFIJGU6b3N4PtfUlerA6Co5+0ZhdWTyMflGFaL5ou/4LB9MfpfmRTRQ8/uTxlD/7QPe8EAtcT4ZOxGwEK0iswWcCP8AQRSfzvy0OgrcjyNMIMAys6IB/JIh08Ed57+QiioWlJfu7O5cH/xAFp6/VV8/AiTxqgeSiF/s1oUdUNSg6ANxzvFSXD50FHFHmhC6tS9EQuqJIXdbuLkguYGMhMni6bFgdO1ZE4QDDF72H3s668nuSlee49IFNx/AC5vYeTLSCw0XPLiNucKL/hn0mlFfmKTHQw/1DSxZfd7KsHKvRvoTkuLn3MD8NGMqLB3QYFlbPS1TqdgKMJo7cqBQ/s9+TOyCtAg X-Forefront-PRVS: 083691450C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(6069001)(53754006)(52044002)(57704003)(43544003)(24454002)(164054003)(479174004)(47776003)(76176999)(54356999)(50986999)(66066001)(4326007)(40100003)(122386002)(3470700001)(42186005)(5008740100001)(5004730100002)(50466002)(5001960100002)(110136002)(97756001)(2950100001)(92566002)(86362001)(77096005)(33656002)(1096002)(3846002)(19580395003)(6116002)(23726003)(61506002)(2906002)(46406003)(4001350100001)(83506001)(586003)(189998001)(7099028); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR0701MB1714; H:localhost.localdomain; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0701MB1714; 23:xH0975KkYfBTyc5OaFdbsl5xRwJBszxDD+wvacU?= =?us-ascii?Q?HKtZSuL6P61j93mw7d92V6x2uznIHWFyt2h5XOAsHttJkqrQ1Z4XLWo9w/5x?= =?us-ascii?Q?6FnUsJveYS4ICWXUJX8GD/eHexFcP9iyRRsabRuOAgpTmD4UiC+0tIgIkuJp?= =?us-ascii?Q?czuL4juQ9m61U8kZlbSRZ5JPzQ8KmgcyVKFDMpy03tCUHS4JDjVsJHQxsnbI?= =?us-ascii?Q?9Fou9yCX7/+Ub8NrbfJOrBl9CU+toevTgpAEnH99lUhinTIKPS4lJ5mNPjNy?= =?us-ascii?Q?PsMhFNy8LEaDPMgtqsZnDQvtHg6xFXmrVuD4i8OqzB2+T8oAQwcNRwdBs8vC?= =?us-ascii?Q?VmO47yV77nEJDIMONSGiOO0wkUphWMK81wdH2B4/6TI8kfWH9bam9sVypXA0?= =?us-ascii?Q?3+2OBBkR9ix5GmLsxGKYe7654oU96dEOyGlTMySB9NMrcxu2i/ynYJMPY7xZ?= =?us-ascii?Q?5Ie4TFCNy72e1oy/HYFYs0l8OUE0DbBbwRQBWpJv4nJB+C2d9wj+D9ZSTWd3?= =?us-ascii?Q?urUaNCI88JzdZzjYQwtiiZDxeA6E03Ok4CPrJsH/boE+vd44XvpD4vGTnFbJ?= =?us-ascii?Q?Mb82ooIPzUsequ1EZJbxRft+rBvvvBT5aYUuKfueWIgZ4xaOWF1jJRbNgPnS?= =?us-ascii?Q?ZXzD6edxAegnX7B36aDHfyk5lFqsYC2Av4+gUhfyOxmMbAcvQ8nD43ttaiVa?= =?us-ascii?Q?Bp5Lbl7BvW13uEVxqVbo/ycrfDlmNVZE88Rv/0OV+rKdfRSqd4enV19fX1h1?= =?us-ascii?Q?HwBkDaVlTiUQFI3DDt5DWFFVdyveoqQCJtXDspeec+dIaDdPkH9vIM1bsuWv?= =?us-ascii?Q?m5UrvAFMg63oxtTg+pa+h7puU8oHuaHZhF+PwFkg8o2eHr+wVFLPiXM9DNBk?= =?us-ascii?Q?IuA1rEs9HYzrkgst/sOiBzjy6YAgb+sA4XTWB14xRgV3wfui26dvX0RUOTW0?= =?us-ascii?Q?0JGkdNF0echW04ke17mZ0qXmxtGliCz9N8KcXyxd465g6LPGT/Rf/zqu8RQC?= =?us-ascii?Q?oasW01ZzGGYxMBgiu3hP1fhOr/5wLrzWowLIIFIFni4AoSFSGFyPy7mfwQ4g?= =?us-ascii?Q?IQtLAANBGlGbvOfK+uDb9wBnHTe16jJ79bHoWM2N+u1URTCwkAH/NgNKbzL9?= =?us-ascii?Q?GcB2l6lvsgj8=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 5:dr8tkOVuHFgB9AU9yO94/5/e60jMxubZsdiGeJ7XKOk8wdHuwl+I5UY7TebBIqs1x0eR97Bu7WDJOUyNT+IXwpUcOst/nO4REzc7s3r73H9wC4YbP87RsDBQ9LWpPhksc7qqOpy/GdenpCEgGkPdLw==; 24:+giyt6JdKe9RRimy9StYFffycLiSOaZ1xf2fdm8lopho7EoICLqlYggR07nyxARAHgXfXnR7UH4jFbVo/C459a1Kgx4boB6ijHdcB280XKk= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2016 17:17:01.1640 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0701MB1714 Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 0/5] add external mempool manager 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, 29 Jan 2016 17:17:04 -0000 On Fri, Jan 29, 2016 at 01:40:40PM +0000, Hunt, David wrote: > On 28/01/2016 17:26, Jerin Jacob wrote: > >On Tue, Jan 26, 2016 at 05:25:50PM +0000, David Hunt wrote: > >>Hi all on the list. > >> > >>Here's a proposed patch for an external mempool manager > >> > >>The External Mempool Manager is an extension to the mempool API that allows > >>users to add and use an external mempool manager, which allows external memory > >>subsystems such as external hardware memory management systems and software > >>based memory allocators to be used with DPDK. > > > >I like this approach.It will be useful for external hardware memory > >pool managers. > > > >BTW, Do you encounter any performance impact on changing to function > >pointer based approach? > > Jerin, > Thanks for your comments. > > The performance impacts I've seen depends on whether I'm using an object > cache for the mempool or not. Without object cache, I see between 0-10% > degradation. With object cache, I see a slight performance gain of between > 0-5%. But that will most likely vary from system to system. > > >>The existing API to the internal DPDK mempool manager will remain unchanged > >>and will be backward compatible. > >> > >>There are two aspects to external mempool manager. > >> 1. Adding the code for your new mempool handler. This is achieved by adding a > >> new mempool handler source file into the librte_mempool library, and > >> using the REGISTER_MEMPOOL_HANDLER macro. > >> 2. Using the new API to call rte_mempool_create_ext to create a new mempool > >> using the name parameter to identify which handler to use. > >> > >>New API calls added > >> 1. A new mempool 'create' function which accepts mempool handler name. > >> 2. A new mempool 'rte_get_mempool_handler' function which accepts mempool > >> handler name, and returns the index to the relevant set of callbacks for > >> that mempool handler > >> > >>Several external mempool managers may be used in the same application. A new > >>mempool can then be created by using the new 'create' function, providing the > >>mempool handler name to point the mempool to the relevant mempool manager > >>callback structure. > >> > >>The old 'create' function can still be called by legacy programs, and will > >>internally work out the mempool handle based on the flags provided (single > >>producer, single consumer, etc). By default handles are created internally to > >>implement the built-in DPDK mempool manager and mempool types. > >> > >>The external mempool manager needs to provide the following functions. > >> 1. alloc - allocates the mempool memory, and adds each object onto a ring > >> 2. put - puts an object back into the mempool once an application has > >> finished with it > >> 3. get - gets an object from the mempool for use by the application > >> 4. get_count - gets the number of available objects in the mempool > >> 5. free - frees the mempool memory > >> > >>Every time a get/put/get_count is called from the application/PMD, the > >>callback for that mempool is called. These functions are in the fastpath, > >>and any unoptimised handlers may limit performance. > >> > >>The new APIs are as follows: > >> > >>1. rte_mempool_create_ext > >> > >>struct rte_mempool * > >>rte_mempool_create_ext(const char * name, unsigned n, > >> unsigned cache_size, unsigned private_data_size, > >> int socket_id, unsigned flags, > >> const char * handler_name); > >> > >>2. rte_get_mempool_handler > >> > >>int16_t > >>rte_get_mempool_handler(const char *name); > > > >Do we need above public API as, in any case we need rte_mempool* pointer to > >operate on mempools(which has the index anyway)? > > > >May a similar functional API with different name/return will be > >better to figure out, given "name" registered or not in ethernet driver > >which has dependency on a particular HW pool manager. > > Good point. An earlier revision required getting the index first, then > passing that to the create_ext call. Now that the call is by name, the 'get' > is mostly redundant. As you suggest, we may need an API for checking the > existence of a particular manager/handler. Then again, we could always > return an error from the create_ext api if it fails to find that handler. > I'll remove the 'get' for the moment. OK. But I think an API to get external pool manager name should be required. It's useful in ethernet driver where driver needs to take care of any special arrangement based on a specific any HW pool manager something like below, feel free to chage the API name, inline char* __attribute__((always_inline)) rte_mempool_ext_get_name(struct rte_mempool *mp) { return (mempool_handler_list.handler[mp->handler_idx].name) } > > Thanks, > David. > > > > > > >