From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0087.outbound.protection.outlook.com [207.46.100.87]) by dpdk.org (Postfix) with ESMTP id DD82CC39C for ; Thu, 9 Jun 2016 12:31:58 +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=CGUdqYfNTmQxSw3NhTEuBmWAhm8XAhT4xelWwzOx3QQ=; b=djY1PG7LLJcduwgOSazCaP4Wz63m4JmdMGi7E/9gUXGXSMPBsX8QR5z63ieyl42P8THGhykOh/JxXk94F2j25JD8QP4aWI+suGRcDP3tPpWKgUrdmEaa03eitMo6LFOFW4eEuKrmDj4UUTUxnChXuqzZ+syhn9TjLr6idKu9cw8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.Jacob@cavium.com; Received: from localhost.localdomain (122.172.248.65) by BLUPR0701MB1714.namprd07.prod.outlook.com (10.163.85.140) with Microsoft SMTP Server (TLS) id 15.1.506.9; Thu, 9 Jun 2016 10:31:53 +0000 Date: Thu, 9 Jun 2016 16:01:34 +0530 From: Jerin Jacob To: "Hunt, David" CC: Shreyansh Jain , "dev@dpdk.org" , "olivier.matz@6wind.com" , "viktorin@rehivetech.com" Message-ID: <20160609103126.GA27529@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> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <57593962.6010802@intel.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-Originating-IP: [122.172.248.65] X-ClientProxiedBy: MAXPR01CA0009.INDPRD01.PROD.OUTLOOK.COM (10.164.147.16) To BLUPR0701MB1714.namprd07.prod.outlook.com (10.163.85.140) X-MS-Office365-Filtering-Correlation-Id: e188fbfb-5f2f-485d-9504-08d3905147d2 X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 2:BeLn9ID4qIPPvatfYWGH7YYwIoGZ2dg7xJk6afA6AWdqhx8Ked9GMm7UKJAnQ82PJ77RsXG+6uRmsJgA2nFPbzyzR23GJlzpQT9QE7pdckF3YVpiwgNgY9QVDy6e6YKNUlUlbq6ZdaPJ7vZYRXw38PCYN2iMTA8GEp39U9TGpiHy/d1MBLFYe6WQ5mdojfxi; 3:nCvkJd/G8dboE/Oc1XhExmrTudOo+59Lp9upG1DOqgTvIY7eMuDpaXhO0uMZFgo/e0rNou7s9oRYD0S/okXZ66q9fcj96NVhQcMRMpn/DZ4salQG0KbFnUgsUM4gjmbm; 25:knzHvySoLypm8jrXA2+tVq4NsE/i/7ec7WnXReOcJrG003h3aZow83+3SBkDBPuX9ZfUzi2tmRRsZbYPnlMYbg+3qjiEA91aCpH3B5qpTEmZBXyzEKrgJkoqGRCadS1Y9rR9/8zqpCg7s6xJfkGw0wAsJnKfcXpiquhi8apkDUrAMmThCXkDjyf3HfdMaeWUTniRCymKqH9eQqxTtAv/omLq+K34FFtxBwQCCKYtG/w0n7VMiyWDfD8kMAhLqVwEvey/5kYUUM7xUg+CW5D6Qj0q0lA1kHqGoR/fhMue+W+nOiCmJuvDFFRLEZ2E/zS6MoT8OgqqJrT24B0IQMrRWl+/NcWDJtOymBHCgbUquA6EzSeTOBx7U16VOD8Qyk4p3c2SMivYDFpV2LkxmNOgrSGAD5bwfpdzus8ixneN7xM= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0701MB1714; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 20:TXJvMwgOqd2sCYejvaDDy385sL2quwRajmsZPFr+Yw5RHyR5vw5Lv6TkXG8goSch3Q5Hq+28YHJEdi5ztLHFBRS56HQzbLmaeBLilmK8A1hGcvPu+kqy6Ri3wcNOjkwpAmgcjvyIckECTbQT3pPLzkxenEtVL2FiYvlycYLFlj/3fXklKnmfMmG6cT0zZfu6dLUgRfQqOTzqqPPKo+bRkB6als62atsa9O0IlqhK8gZV49LQHfn/pmj6EvBoj6vTfkcqP3JyZmwtTab4fTu/p6M8djQZcf2yCdmOrbhDROzh09cCTi7Xw4Zs9xl0ypr2Yson26cOuSlkfv0+YN4kmTpO95pz9u5RZHjucTHHZz93PagP/9EA5lcGUeJlPvDe0qVKCP7uUx0UttMUCTCrerI+BkTKtWcUcs16uO0fx9NSkeQtE15Sec6+8p/qfpDFvKofG4VwjPIj4/i4Dx7PsnGTryVCMJURSOgqj9jzruf/6cU+8TVGB7PBxoEZxp3Hro4O5V+FiEX27wU4R0NHBLo4Es3k9Gg7dIyhGMBBp3VKi3OZNPBL27hCFLxiVWuMDynEBVZEv5Rhfp79YKidUOSFibDKPevt7Ssn5nvCzbQ= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(185117386973197)(788757137089)(228905959029699); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BLUPR0701MB1714; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0701MB1714; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 4:25qR38MvtlkUI/qRAJ5Ou3LlvjpMjIaRTRlOseFDUJ92lF7L236YVExI6kSyRJ7XZcW9Y96rMOg5CQ4gZ/xVFnsGMWsbWZl+IPgtm/bfgKUhqo6joaX4ikgawFwL8umW4dr5ASxf88TnZL9MlFzgPrBqxlLSE8Eoki+UbJRhSXYxOZDgd3zv82nNR8MeqwIKH7vgC37E7BmyFpyTE2QuWZQojVee5VwGg+IFi8R4x1kyI5KCwyuI2E6SxK7YCv/j5YufMoqIqB/D8UfkiYrk/XZ4lG2nDkLfmWKbS4WnturqCLmmvyeiAm6Mx+H2cwTs3sPDpSpKsYF58m+rckfgV3KdMQLGGBPBwEkRNNDbE3kj4CY+TZhDxDiswy9qUkYRCsGnP69N9j5NGtyi83n9u1NOQWA2OOLy85EwjhclOzcZV1eVIBLy6+LQBqvHOWkm40psS4qf+fGgY6hw8SpsS4eeAhLIP48//O6v+JY9CjCdadkjwe7uNgXiYaUp0hKF X-Forefront-PRVS: 0968D37274 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(6069001)(189002)(377454003)(199003)(13464003)(24454002)(81166006)(4326007)(8676002)(5008740100001)(81156014)(66066001)(1076002)(586003)(8666004)(23726003)(77096005)(4001350100001)(46406003)(6116002)(42186005)(68736007)(61506002)(33656002)(97756001)(97736004)(189998001)(19580405001)(5004730100002)(19580395003)(93886004)(3846002)(92566002)(47776003)(50986999)(76176999)(2950100001)(54356999)(110136002)(2906002)(83506001)(9686002)(50466002)(101416001)(106356001)(105586002)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR0701MB1714; 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; BLUPR0701MB1714; 23:IOIcDvOub2pdTKnnzznzC9XbY0bXe3+dY5uin4y?= =?us-ascii?Q?j8IrSAWYyr1ic38ioxAV7uWwJWiKCm03cCi98pdsFXG6ETvZm4e8ueFokSAo?= =?us-ascii?Q?mazBrSSAC5TbzVyuPA9ZajCkeMyH4Qoyf+myTqiSVMwp+rEJKovDQompY8+f?= =?us-ascii?Q?5gkcglP3omcJTZQWquraubPwf5XBNkgheNCXo5IltPTSlXnRBdeN2Pr9KphN?= =?us-ascii?Q?xarDVxWjQ5QiRJPCJyfrqdPOL4VIRebEQ9p7uPHhtqtnekPP15aBncjeQtOl?= =?us-ascii?Q?yNE/ROJXwOxDFO1oj1WHNKBZlOn3brjI3iGKKWU6EkxsYl3odZ8VJ05mvIix?= =?us-ascii?Q?gqmfH8EK+DhoZUV7arrQrUo6mz5lc+x5djIYy6PIF8SRA/UtQYXhhbzN3Lsm?= =?us-ascii?Q?mpG2Kkb9DdwB8ENNhXdbBCbLxsw6pSAQr57sUPkQoA1L0sd4VGLg7ZUq1qqF?= =?us-ascii?Q?finvCehg2YZuNfkQkudTQHb7fVYOIVwbk+ZRLvPpio4/w6fNfNcsHzP8I0Rw?= =?us-ascii?Q?l1F6SEvX/LgeacDdLqHPZvKT4y7OFbEkIIVMbLhTsmwBiJD55NXMLXjdVKLz?= =?us-ascii?Q?936qs/4qhKK0OCSai5UTvfbH1PrVExbklFRaACc4Fp6Ia4PwnXiUx/5vXflU?= =?us-ascii?Q?lGB8ZjMdX8v8n7H9/hmCK0V6vC++BNSse0DAH/PTcvFKYrthvooBZO3i0cHA?= =?us-ascii?Q?teydILebv5qp1MQlx6h7jx5dUFADl+/uf9h0UxbhZhy1l7xCLjWFD6vMmjFa?= =?us-ascii?Q?mGHLX4kn31lKnvDYBc066bdHprIqsGSFa9bu1pYplQ1gBjdFbDbDrauq097h?= =?us-ascii?Q?4io9sZxtqU1NpW5uhW/Os72dK1nPZF88hSjcrmLu8kUpZ1akp+03U5hcoLQ3?= =?us-ascii?Q?UphBzmWmnr/kCSwfBRZVMZ/Zmn27lhQ2KRn6tSFfC5fFDi7ET9a2DEDo0rdV?= =?us-ascii?Q?2sImsP8smMU+zWkwQGA9ZJsOc29p4eDHWcMzmy+QASBzFoT47d5ULwnFXJOp?= =?us-ascii?Q?v4iCA7YxvZTRZNPoyKFCyYQWs1cdRvOSV03cXPfq/zUxP/W9nzO4jUPV0JfY?= =?us-ascii?Q?YfObBASh/dpK2XE8LwUZLcEe6vHfRT1f/JKE8iypbGzQ5LHPZ5BqHUmaIRiS?= =?us-ascii?Q?gZhw6yivXhx9CKjBK7UnC+eU7nuDbncVDsUeQ/eb4N4hLrTjJ3GS5iB2DUew?= =?us-ascii?Q?4vFE7lKkyElqJHvaFVLw8u5Cr7FiPF80wYd30cGiUk3NSYnwh6eGdMHhA8g?= =?us-ascii?Q?=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 5:aSPBwehss4VNk3gLFLja4eVxxTqykt4LG700A/nMSuYFvRMB9cd7Y0XRU3VcMTCL/A5A7GLdz79+YrxpidAgq6FsMV77nNvpS0AcnE9fX/CKjE5MCLl+EBZfCKuX/31UoJGhmgH82ai9VdZ5WpgB8A==; 24:O45PDoN3XRMHxrW2nXIwc9W0rwlvCZAEul1bda6poOewbyKWEmsd3MNojHZC3MbsAWUff5kkHq+1+yxXVeZn7WU3GFEzPjCQEc06Cm8TLj8=; 7:OcXTid4JpReqIqIX6pKGbKl5T7mFOaIU+gnVlzwXwyB4Sywql2QNZzaZUrCVO/fREhTy6qr8uC1cL40+potXXlsd6M9Bw8BllL00st4PgnNxjiNb6DYvqPa4lMkgeKtjGEQKR1kXFb6jduAPxSyECxYp3SwSchQIsx2R5q5LYlfdXnaNUf6WIvpypF6tQhSrgTaPlgXkBc66B0bSOIKLbCkdPO7ukXo7tMm3ghmOhu0= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jun 2016 10:31:53.8917 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0701MB1714 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 10:31:59 -0000 On Thu, Jun 09, 2016 at 10:39:46AM +0100, Hunt, David wrote: > Hi Shreyansh, > > On 8/6/2016 2:48 PM, Shreyansh Jain wrote: > > Hi David, > > > > Thanks for explanation. I have some comments inline... > > > > > -----Original Message----- > > > From: Hunt, David [mailto:david.hunt@intel.com] > > > Sent: Tuesday, June 07, 2016 2:56 PM > > > To: Shreyansh Jain ; dev@dpdk.org > > > Cc: olivier.matz@6wind.com; viktorin@rehivetech.com; > > > jerin.jacob@caviumnetworks.com > > > Subject: Re: [dpdk-dev] [PATCH v8 1/3] mempool: support external mempool > > > operations > > > > > > Hi Shreyansh, > > > > > > On 6/6/2016 3:38 PM, Shreyansh Jain wrote: > > > > Hi, > > > > > > > > (Apologies for overly-eager email sent on this thread earlier. Will be more > > > careful in future). > > > > This is more of a question/clarification than a comment. (And I have taken > > > only some snippets from original mail to keep it cleaner) > > > > > > > > > +MEMPOOL_REGISTER_OPS(ops_mp_mc); > > > > > +MEMPOOL_REGISTER_OPS(ops_sp_sc); > > > > > +MEMPOOL_REGISTER_OPS(ops_mp_sc); > > > > > +MEMPOOL_REGISTER_OPS(ops_sp_mc); > > > > > > > > > > > > From the above what I understand is that multiple packet pool handlers can > > > be created. > > > > I have a use-case where application has multiple pools but only the packet > > > pool is hardware backed. Using the hardware for general buffer requirements > > > would prove costly. > > > > From what I understand from the patch, selection of the pool is based on > > > the flags below. > > > > > > The flags are only used to select one of the default handlers for > > > backward compatibility through > > > the rte_mempool_create call. If you wish to use a mempool handler that > > > is not one of the > > > defaults, (i.e. a new hardware handler), you would use the > > > rte_create_mempool_empty > > > followed by the rte_mempool_set_ops_byname call. > > > So, for the external handlers, you create and empty mempool, then set > > > the operations (ops) > > > for that particular mempool. > > I am concerned about the existing applications (for example, l3fwd). > > Explicit calls to 'rte_create_mempool_empty->rte_mempool_set_ops_byname' model would require modifications to these applications. > > Ideally, without any modifications, these applications should be able to use packet pools (backed by hardware) and buffer pools (backed by ring/others) - transparently. > > > > If I go by your suggestions, what I understand is, doing the above without modification to applications would be equivalent to: > > > > struct rte_mempool_ops custom_hw_allocator = {...} > > > > thereafter, in config/common_base: > > > > CONFIG_RTE_DEFAULT_MEMPOOL_OPS="custom_hw_allocator" > > > > calls to rte_pktmbuf_pool_create would use the new allocator. > > Yes, correct. But only for calls to rte_pktmbuf_pool_create(). Calls to > rte_mempool_create will continue to use the default handlers (ring based). > > But, another problem arises here. > > > > There are two distinct paths for allocations of a memory pool: > > 1. A 'pkt' pool: > > rte_pktmbuf_pool_create > > \- rte_mempool_create_empty > > | \- rte_mempool_set_ops_byname(..ring_mp_mc..) > > | > > `- rte_mempool_set_ops_byname > > (...RTE_MBUF_DEFAULT_MEMPOOL_OPS..) > > /* Override default 'ring_mp_mc' of > > * rte_mempool_create */ > > > > 2. Through generic mempool create API > > rte_mempool_create > > \- rte_mempool_create_empty > > (passing pktmbuf and pool constructors) > > I found various instances in example applications where rte_mempool_create() is being called directly for packet pools - bypassing the more semantically correct call to rte_pktmbuf_* for packet pools. > > > > In (2) control path, RTE_MBUF_DEFAULT_MEMPOOLS_OPS wouldn't be able to replace custom handler operations for packet buffer allocations. > > > > From a performance point-of-view, Applications should be able to select between packet pools and non-packet pools. > > This is intended for backward compatibility, and API consistency. Any > applications that use > rte_mempool_create directly will continue to use the default mempool > handlers. If the need > to use a custeom hander, they will need to be modified to call the newer > API, > rte_mempool_create_empty and rte_mempool_set_ops_byname. > > > > > > > > > > > + /* > > > > > + * Since we have 4 combinations of the SP/SC/MP/MC examine the flags to > > > > > + * set the correct index into the table of ops structs. > > > > > + */ > > > > > + if (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"); > > > > > + > > 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? 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) Jerin > > Regards, > Dave. > >