From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0064.outbound.protection.outlook.com [157.56.110.64]) by dpdk.org (Postfix) with ESMTP id B7F1A29C6 for ; Thu, 9 Jun 2016 15:38:01 +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=2yzzb+o6UZQqRBFl6kEpHtmU2KSq8QniMFC9MoOOPGw=; b=MVXfgZd5cdzdJtQ69SOjf0KvNQth6YJW7dXhsonK+1WExTzQPsQXnKuLwQM22syDKbsH/jwk3U1oqtHR+WO/hy26St9d0d9eJfZTcx1ZmxdOt9f6ct4jrj2hhIbETae35VskizchzLYEm4wVOjZ0xc/Fv6f2cOVcADnzMAsTzu8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.Jacob@cavium.com; Received: from localhost.localdomain (122.172.248.65) by BN3PR0701MB1720.namprd07.prod.outlook.com (10.163.39.19) with Microsoft SMTP Server (TLS) id 15.1.511.8; Thu, 9 Jun 2016 13:37:57 +0000 Date: Thu, 9 Jun 2016 19:07:36 +0530 From: Jerin Jacob To: "Hunt, David" CC: Shreyansh Jain , "dev@dpdk.org" , "olivier.matz@6wind.com" , "viktorin@rehivetech.com" Message-ID: <20160609133730.GA32271@localhost.localdomain> References: <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> <20160609103126.GA27529@localhost.localdomain> <20160609123034.GA30968@localhost.localdomain> <57596CC1.8000509@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <57596CC1.8000509@intel.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-Originating-IP: [122.172.248.65] X-ClientProxiedBy: MAXPR01CA0064.INDPRD01.PROD.OUTLOOK.COM (10.164.146.164) To BN3PR0701MB1720.namprd07.prod.outlook.com (10.163.39.19) X-MS-Office365-Filtering-Correlation-Id: bf1eb8a6-1098-4141-2bb7-08d3906b459b X-Microsoft-Exchange-Diagnostics: 1; BN3PR0701MB1720; 2:DDrcnhCCr6ePzpGFtV1QeYKBku2qx7An2kPuPT3C/q+eSug9+SroxoDjMKSJEeGKF3dgxNM/VJOgK+UIi8oLXQvMLeYyuWPXwgCPjnSqFakfze0sNrYTEdVOyIm79DjxRv5KHq5ezU+gVM8VvkvEATPUUhu/4hvSLQeT4Q5ksjdd9zJwku4yBDLWJ/DudDP0; 3:VgIPQywpwcHY8EvqdvPBZgEQXc7U8h6lRY8ORUQbw7SN+SKHU88qCXC9FfQtDR+D8X6r+9wFZIuJoiPIMK8tVsmanusIlUB7TRphe1MwFSNlFNks11M5q6H/shdRR1xf; 25:VDzlFiqQ0ntonM7ykRW5pMMAvS1Qn/FmcXOWxuA5+KpP0TyK4D2oG2Tu5STHNobpa4oquUFjIVJb3X7v+9D0oR2GIyuCyctY/TUAa2CBHamDK4vTzj6EDvnTPseDXSUDh5qAgYO324DzJ0DRF56+p8IeO/EQmOLgRowbj07y90wX8KZTbqABUTU0zgt9BDW2ivz1MX1ACzNwvAGzD0qOkJyd8Cg3Hapb5DxPR+QRUqKLmk0CEy7u+KViucDSTmzA2J6To7g4uAxF5yuRA32MyTvNWuFs2nl1ILVHFOFOWK9f/Snx7QbuJgindlIdHbSLx0alr2iVlg/hyg15DQIpGY3gOqH7IZ4Szhn/BDxIvoo+I5CT5ye9iRR1EhJhmH7GKfqGPlMmtFt9+/KHRz0ufjB/XzjQlCh38+Ggnll1xBc= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0701MB1720; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0701MB1720; 20:rjLWyAEb2srReJonLKxyMhqXCL97jFdpF9OCCr+0Rwhp1u2CXpr1QEDJUNk/DTGnfYz1MgOluF2xZvP1S1cmMVLvEbBqipJheZM137gubcCHEaI/GoSgFhdJBN+BFhYQYiXcbzp+vOo9AYEHqJhS4ecPlzyAGSvB1faIuriOytQmCiAwPiD8iUaISch1GNcG6uTTPuHNq2gDJY6z6bPqjeKLNRw9APiun2I9/ddp1uwX7v2inH2n/IZibeY6CRx5qPSDvF0Pk6RiA4zrtwiE3l6jUcdyWZpP55xcP04gOyyeeySn8ZwTAveZEUfnOIlH1IhpRSy6uxZfBVTLPX2/GLeUZ3RVvQOJkTEBp9d9YsnpV2TrUvhPyBYt44fRi0K1ObpPa+jwZBjrirnpYguxlR2zpoq2HaulmnGZrbtwzWrAW6odkYirIGlYh8CioEkYoF6HigOuI83pz/wmeKWP8wfBAyTI5+yQ6mKvItgn3yIres07KggEjbAEAGdxGuVQ5WbZLtUCcd9FHiKoCwA4qZTwa5QgHkdwYeonTtSFVP/peIf2F8/v9exAzA18mvZQ72EEnQvBsZ/1NImCRmIi8kuIu/Qfuwk85NCJLI15kyc= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BN3PR0701MB1720; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0701MB1720; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0701MB1720; 4:xDFkT/L1BLFhoojVE8bDR7u0keQ17c+q8LrYEeeJPI9FU4LhTD5xNKZpeMIIA47lbIs+pqY1Td/MX4Y8PXnTmhyG7+WLiEW0iH+hJBirIG96UwHx0926NQeiEILDSD1+G4sVaVhjB4BNDgekUkkjjkW8Htd1bqbHJdUZ2K2yLX82vuCE39tCQ0Pm1xsAtW6BRGhqb8KCiKw/xmMC4zIRZKY9Dzxza1rMp1pah8o7Vc35NYTVNMCqHqxCM2Tm9w7BobOlp5W3VcsSP9yL+db4k6KKeyiFIT8IRTHRae+dZ5fhvBDhm0ciOoXreD6OtXJNiipdXW9/jJ7HtxVWx9E7G7qhXdpqrNnBm6WjvD+g0D6ZrJXVuqb4lfIM6wrazw786r6rCzUWeiDPVPRXLMxjYRwkKpHgdjNUOjiFgoCe+Qk= X-Forefront-PRVS: 0968D37274 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(6069001)(189002)(199003)(24454002)(2906002)(8676002)(42186005)(93886004)(92566002)(5008740100001)(50986999)(2950100001)(54356999)(5004730100002)(76176999)(33656002)(9686002)(77096005)(189998001)(101416001)(50466002)(46406003)(110136002)(66066001)(68736007)(47776003)(8666004)(97756001)(61506002)(4001350100001)(81156014)(81166006)(97736004)(106356001)(4326007)(23726003)(83506001)(105586002)(1076002)(3846002)(586003)(19580395003)(6116002)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0701MB1720; 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; BN3PR0701MB1720; 23:yfatdkGF+MvPHEXoTk72STXy9vJXYuXi8GkvGHm?= =?us-ascii?Q?sNje6aC5yIuNETB/3dPJTNEo+7o1/qx5e6ftCJKmO06F/FItyN8BeXrqAIdF?= =?us-ascii?Q?c5gCyhn6MlER6cZ06PMqejG8rAATINKQL/qLKOJInxkd4b3QSCtu8zoi3ZAf?= =?us-ascii?Q?Fcndr4m9snHDmrhvfA8gDaPEFr2S18idX1K1+xMmacqC01OzSFDpUw39E5tA?= =?us-ascii?Q?r9QOYFwmotnViCT/p7pycitLUk7BzfYeF7SbJxNVUlrdvNLu5YlBQhP51cCH?= =?us-ascii?Q?/OBr07BORwX9PtQLPKfK08qtyXg0TSxD1cYKtKQBjfWVUrHRa5zGeJ7Y/pOO?= =?us-ascii?Q?FcN/FglsKTEq/YjZUEa9vL8DrgLjBts5hAvwKR6UWdSqKKV9rufxnuPRgnaS?= =?us-ascii?Q?485cfEDrPrsBXrMM4GU9H2aqtJgZndIZaf0q7c8svxVJHCM+zZlcm3prdxVc?= =?us-ascii?Q?nQWUmmx9HpJTrlepb6lvfvvYMEJ407dW7B3qukUIEkExnYqZBM2dRkf77DCR?= =?us-ascii?Q?lXIwRPyt3ehhAAuS9ZqNkPI4G3cvzZpjhkRZqmzt60lKV7MzE+JSns0/ryJi?= =?us-ascii?Q?Cyp0Z4yCUx2+lkFwE+4vQ/uwJDcpp3iYH1yBTRSpwb36+aA01bN5xmVbo5Ul?= =?us-ascii?Q?SZgMZnYpC25AUKrpx0fpFtuCNcfI5Wgj3hyqfKg4HMI9qFjcqqxNN4rqKecv?= =?us-ascii?Q?mBbTWa77q7BXrFzALbKD0zTBCwLvNK37H34Y9ex8/IpgZM3mAg3d3+UElICb?= =?us-ascii?Q?v0bSBu3ryF9MIf4+GrSxbrB0Fm/sIAphaMT8RcCLw4086e5sLD4M0NzM+wK0?= =?us-ascii?Q?vZLnm1Z2owFduoGKNa0KPUJxQ7UHrtzU3xufbAiOXNcSVTFeJnNeAZMhgcqp?= =?us-ascii?Q?ttZJOBH5fH/YwRkU2WRQwvMYrbqjli2GP8V8LtcD6BLsj0lw4t+Xn3irxJEL?= =?us-ascii?Q?pl9sofgUHTA+WaeCGdyDo0LIVo2XRjS+LL9GNkxCoVDwZ5KIIPS1WhtaQEHb?= =?us-ascii?Q?T3V207HdlZ/gVFlLfRPBMHgHSQfleyZNBxv91aNIr4I6MPRFUvTbqWg0ySeV?= =?us-ascii?Q?ltP2aWzqQAZrDcKkzBxG+aGY07T2GMX0NVGFcF4XfykAg9t7C0IOLot/ogD6?= =?us-ascii?Q?sbCr8MYC0sdldYoG7wVqDlqd/m7dlsLFxuAOiqMFI8/nhamqmcQGpOQ=3D?= =?us-ascii?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0701MB1720; 5:8giZcRmTQsxcbK+c3dB04ThmseFypc+gugH7Noj1ABvFX1AtINuApeC4KOMDRP7nEwCrySmtOUN4ZFoaV+YiPOc6vf55sXChyk2PMLEPDcbyY/5E0F39DWi8GOjFy4UL393oJiYGZq/AaDl8imoeIg==; 24:9arbjuh0E+RtLUYdrOblLFir8ATH5N/MUX+mI6RlvO144MEZcFxKtANJ3/XopAQeH8S4cn0uRAkEEdlbKbMiVH+bj0vprdezvgSv9oRhJD4=; 7:IqeY89wdPIhnC6H9sVEHDa/uwPpHiWHClxdDKoHqGxLzpo3HV8L9qONaDs/zBsStPtN9y4wqLYh9SW3JT22uEUPeVzeGtEs7nUStxGQgSy/PiYvLiREjtVH8Ee1Kk2wu5aHCYwMDH1UzAkO4qoJEA9qr+jYGrWE/Jt9dkc6NnHQYokxypmLLQ79tp9m/dJU7ZnTXJrPAFqiEjZ+jiXpIGQ== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jun 2016 13:37:57.1818 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0701MB1720 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: Thu, 09 Jun 2016 13:38:02 -0000 On Thu, Jun 09, 2016 at 02:18:57PM +0100, Hunt, David wrote: > > > > > > As I mentioned earlier, My take is not to create the separate API's for > > > > external mempool handlers.In my view, It's same, just that sepreate > > > > mempool handler through function pointers. > > > > > > > > To keep the backward compatibility, I think we can extend the flags > > > > in rte_mempool_create and have a single API external/internal pool > > > > creation(makes easy for existing applications too, add a just mempool > > > > flag command line argument to existing applications to choose the > > > > mempool handler) > > > May be I am interpreting it wrong, but, are you suggesting a single mempool handler for all buffer/packet needs of an application (passed as command line argument)? > > > That would be inefficient especially for cases where pool is backed by a hardware. The application wouldn't want its generic buffers to consume hardware resource which would be better used for packets. > > It may vary from platform to platform or particular use case. For instance, > > the HW external pool manager for generic buffers may scale better than SW multi > > producers/multi-consumer implementation when the number of cores > N > > (as no locking involved in enqueue/dequeue(again it is depended on > > specific HW implementation)) > > > > I thought their no harm in selecting the external pool handlers > > in root level itself(rte_mempool_create) as by default it is > > SW MP/MC and it just an option to override if the application wants it. > > > > Jerin > > > > > So, how about we go with the following, based on Shreyansh's suggestion: > > 1. Add in #define MEMPOOL_F_EMM_ALLOC 0x0010 (EMM for External Mempool > Manager) > > 2. Check this bit in rte_mempool_create() just before the other bits are > checked (by the way, the flags check has been moved to rte_mempool_create(), > as per an earlier patchset, but was inadvertantly reverted) > > /* > * First check to see if we use the config'd mempool hander. > * Then examine the combinations of SP/SC/MP/MC flags to > * set the correct index into the table of ops structs. > */ > if (flags & MEMPOOL_F_EMM_ALLOC) > rte_mempool_set_ops_byname(mp, RTE_MBUF_DEFAULT_MEMPOOL_OPS) > else (flags & (MEMPOOL_F_SP_PUT | MEMPOOL_F_SC_GET)) > rte_mempool_set_ops_byname(mp, "ring_sp_sc"); > else if (flags & MEMPOOL_F_SP_PUT) > rte_mempool_set_ops_byname(mp, "ring_sp_mc"); > else if (flags & MEMPOOL_F_SC_GET) > rte_mempool_set_ops_byname(mp, "ring_mp_sc"); > else > rte_mempool_set_ops_byname(mp, "ring_mp_mc"); > > 3. Modify rte_pktmbuf_pool_create to pass the bit to rte_mempool_create > > - sizeof(struct rte_pktmbuf_pool_private), socket_id, 0); > + sizeof(struct rte_pktmbuf_pool_private), socket_id, > + MEMPOOL_F_PKT_ALLOC); > > > This will allow legacy apps to use one external handler ( as defined > RTE_MBUF_DEFAULT_MEMPOOL_OPS) by adding the MEMPOOL_F_EMM_ALLOC bit to their > flags in the call to rte_mempool_create(). > > Of course, if an app wants to use more than one external handler, they can > call create_empty and set_ops_byname() for each mempool they create. +1 Since rte_pktmbuf_pool_create does not take flag, I think this the only option left with for legacy apps. > > Regards, > Dave. > > > > > > > > > >