From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0059.outbound.protection.outlook.com [104.47.38.59]) by dpdk.org (Postfix) with ESMTP id 77A2911D9 for ; Tue, 31 Jan 2017 15:32:49 +0100 (CET) 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=3V/ZtNNK4eTOQeDvtImexWYkzgXgGBoV0IzmxqDu28I=; b=n6hj+sRpE+kw8JxxkNhDixG+aPo2Jm+yT5JZgTZvwgHnB1rGVhan9FPG5bASoT9MvT8RCyd3LTVS+M1Eyla1YraGGSN3D119AYlaW9Ry0VLh29xbxHmKoVQvx6sI+rxulvm9Ofr0ZQG7+FL8lTOQjSbcjO1xDjDImt/JYAdLt8A= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Santosh.Shukla@cavium.com; Received: from santosh-Latitude-E5530-non-vPro (14.140.2.178) by CY1PR0701MB1726.namprd07.prod.outlook.com (10.163.21.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Tue, 31 Jan 2017 14:32:45 +0000 Date: Tue, 31 Jan 2017 20:02:26 +0530 From: Santosh Shukla To: Olivier Matz CC: , , , Message-ID: <20170131143211.GA31464@santosh-Latitude-E5530-non-vPro> References: <1484922017-26030-1-git-send-email-santosh.shukla@caviumnetworks.com> <1484925221-18431-1-git-send-email-santosh.shukla@caviumnetworks.com> <20170131113151.3f8e07a0@platinum> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20170131113151.3f8e07a0@platinum> User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [14.140.2.178] X-ClientProxiedBy: MA1PR01CA0056.INDPRD01.PROD.OUTLOOK.COM (10.164.116.156) To CY1PR0701MB1726.namprd07.prod.outlook.com (10.163.21.140) X-MS-Office365-Filtering-Correlation-Id: 207114ea-e896-4cc5-9592-08d449e6072a X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:CY1PR0701MB1726; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0701MB1726; 3:UG+I8WHBCOWkfEuMz9e75WgyPV98AG9sTyPOm7q0i75lP5BXbZNDyvma+spetojq+9JjcaHIonRGVsMPiz7Njz+w8m8zMW0BWjlRc2m/Xdb4gjrxxoQt4Td+1/NyMvNaSb51bLqp/vfbJiYH1BAloObsVvzJuZZ4vcK0MANC19A06QS8TQTruvNE3kU4P6kiu6eDVqkMr6J6blXhcrsH64vINkJX17vIj7zeOe8zjblAerbONFttkB2ZDK+mSoLtdMOzR5RvjHq8o4ZlV+6GKw== X-Microsoft-Exchange-Diagnostics: 1; CY1PR0701MB1726; 25:ZxQRDZXiuTEa8Xy3F6eAPzxsI2kzVA5rM9O2zWy1NxqjME9Jn6UBAhqOfid5AJnEQN2AoKp7cUY35KRvRJTIhstU02nt96V4rt5vs4qf3jfLJLh7+k9ywS/wpQMiWytf8NUgeVVBBrqoHDTgVG1pkBLfCdu9p6uglpFdJ1BbzwG/4pB8msnqvY9X3wX6t6D7XVbRbuKbiz91GiHMO20t846Hyyv/ZqtO/EDwYmwwhN067LZOVEwqu4B/MI+84FeM12sI57V/yeeJISYihTg87DFrrL1efGhtAFqFegOWAg4BcMau+ljYX6YnQFZJ+C2TbItxlaerzV9jYtHTirD6z3ECuiHkvkuvrPSqfbNIVHqJgpzQP6EQps1/3vj81PcdAcAco1wU5BRhIlB00Z6mr8a525cIBbsVO5hE9G85Yad0T6/q0G5utH0WSx2AQlyIEwmknxnVcS7oUI55V/cqrlBxtVKWM582kP7qf8cTYtEVkfrmnAcoQaW1mFL2XNQ8vtCc9jQFIK86B0QSjBgErOcFr989A/zaxDIco6GdHvLPMoItqzh6upGhVDb3sFm6UwY+5P25/I9TG9Dn82V3g1lxirUeFfpOCN9h2xrskwp+ZcooW/k0nHCAX7qJyV8b64G0bLdSMnSRBtfLeDyJZQ/FViRI/lIjcaucDCR2BC6YNT0ZjaZxauIT0HBT8mcoQP3fmgpiKzdCcoYShXL1MA== X-Microsoft-Exchange-Diagnostics: 1; CY1PR0701MB1726; 31:clTNraFs09jCxSCMhdNIPu0ODB9BHr36KE/UsnAJa6nzq4+JPdP7bxQqyLEsYv4K+4jFHcl6TvtugUkeRf1rvuEjpiJjzBsS/zqxooSe02MpbRsEMcRv3vZe4jl0R8JZ50uu4B+FWTe+ZBdRq2ik73BfCtTSkHN0AYAgVDWFhR3eMbSS9T9zP6JpnJM9UBBVzvFQ/DwWhR57lp1KqN6KSUVe9s0SvDbppipnyY0n057n2FdGf4XeOS5/DkAMr8DDKUtcOIXcOEcLuLzJgxZh7A==; 20:V/R7H5/N7yIq35fPxIM3kEcmzuRNrYg+mHhyYox28eYk3GH/2mrJtVspqnCOoNUFWMeUZ1JWjHmKxcGXOqxRKJmcQd6Ri+HuOQIRglP5Decw70COe/YCpVSCVjR7GciDTUNw/Haa48nIeogpBTgNRjU7b8h3rhJWTKbtpt72QuDNV4Y+lMimDXdzP1WxUGMfIL7dEgPJCYD10mO7LU06v8YU2Y82iTQIOThGag+hrzVHDW/ouGLm76uhrba8PqeeTqLF80M32V0oAMxuiUNfFhPZOGQEJQzvuO6AMMRaLAIiBKAUSQ1basMIxy86heFJgi9nXzRHj1UY4yTn5c2P+h0v5vjZeBqt8/0IsAibFNzr/XVNlqF+ErVxUvKNFlsNk4N8KAvqUnf/InX00EG3UteOV2D7txnNRvxah2vXzMfPXUp5AthdxcdM5uZrHx0s2UaIWrsBLktaeVHYrpBJsXqzP0AEzBNsxgvSGInf8DauPKWLqt/CA7KmNeeUuzfwg11K8+exw7etjH21t8PdUfhxNMlN8DvMAgyjQjdimRf5UyIpU/vqdNQv1U3Gm3qMG5j13704N6VJS4c0mpnJYMMUSaTPu76jbli7A5JJZPE= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:CY1PR0701MB1726; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1726; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0701MB1726; 4:zbqL6FKLII3ZS4g1/M2Qxb9JvuuSYmXF40TuqAZm6NXPKX6YxSSwcWKdXEIcbjdlmimsLh5SBBzgj7f/31PTEpZNgBYg/A2pgPPm/wixU11FOpZZIgykPgTeS6MJFoXQ6vEEMOo11fLfTjV3rDqQH84R5/bDJA4VRnsTr+EMrM3+QD+rmgwneka/7d+ElrYOKQjfjAnE7BXIS1xRK+sLPkJBKYznAKDFexhALTLFeQpsf8N3Tsf5+mKVfF3H6xhMyS2wkNgnWPvDl0rhRKkHq/fv6RFn4k5t+ZrkKrO9Xm7lFO7FGXXf7mjkQpceGXTfsgVOvdWm85vacDtDl5/FtUXJ3WCE4wdT1HSHgfoiLlCYHKqxIeQlxFMKYDQhfygPyCM6ahHK7cLCOZ7FsCp7jMq4d8OrGpEPOi0W7PcHBeuAFVH3IHI5q+HEK+tQMc/5knFzqWb3ppP2QSwppXI/C/NB3SzhcGRXRjNty5jlxATMH/Hl1snOWOhLuRiuLZOLT0+SW+qSnnAJMdglXaRGdcTHaeeH7cyXOOhoY6m08SPRMh8gsIrkSGQPdcgiF6dleT94AhS27g+xhzfnEtn9EQ== X-Forefront-PRVS: 0204F0BDE2 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(7916002)(39450400003)(189002)(199003)(24454002)(105586002)(42186005)(106356001)(229853002)(4001350100001)(33656002)(101416001)(23726003)(9686003)(1076002)(54906002)(55016002)(3846002)(4326007)(8656002)(189998001)(25786008)(2906002)(92566002)(83506001)(6116002)(6496003)(97736004)(38730400001)(81166006)(66066001)(81156014)(6916009)(110136003)(42882006)(6666003)(2950100002)(8676002)(5009440100003)(5660300001)(50466002)(33716001)(46406003)(54356999)(68736007)(7736002)(97756001)(47776003)(53936002)(305945005)(50986999)(76176999)(7099028)(110426004)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0701MB1726; H:santosh-Latitude-E5530-non-vPro; 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; CY1PR0701MB1726; 23:E7Ml+a1NsWWVp6VzqxFpcAfcie1BmaAIHYwkzHk?= =?us-ascii?Q?Ye3vA99npCI4OOvDAOoJfPMYHyrT3LTgrGWXJ69PmkVXfZrtN97uVz9cvR4w?= =?us-ascii?Q?Jj3CRpN47b/2uMRV0O9IhjP/wNNocvqnJLJjxTT8tzla9ssznlogzxng79Hv?= =?us-ascii?Q?NjSeaPYyp1v69JOsxZUyrAzzNBpDZQ2dEdXXdIdGTWnY6hBZeiQuTWB1LJjO?= =?us-ascii?Q?ECYOExwiuFeQLALDHpXWoPySXCe38LDBOgWMJchKBSHCe8EF6jCeonJgDO2X?= =?us-ascii?Q?vvalQDUpc+bYlFZ6H0XnwHH/2Y8/J/i4+L4TAULyxYCUG2A4zabenR84CKVb?= =?us-ascii?Q?wkVXhnS0oPWUH/pi1GQs7HGOe+SFKlLY/jAROIyPVbIVCSp7vUjOFpIC1Vai?= =?us-ascii?Q?H9g/pUNtaI6KEqJZdVjKJuinahlzPC0SHTEY6mYifKM1SCKxqc/K0himaD5C?= =?us-ascii?Q?vvH7+U+sOQMgyRoocLc6asNaEkHYM7nn92CK6uJevdBnA6RDj1xIF6zKVziC?= =?us-ascii?Q?q2n0D7JpGNpLB1/CWpehZEmgtqngAIqFSZYUDPTElkER1iz/Z5I9Y3c/GF8r?= =?us-ascii?Q?96qul8cVB/Bg7u4j0wjAAewEhiRj21eEu9ObeBKi22Grb+XW4a5WrqvEZF/y?= =?us-ascii?Q?Otls9fNoN5y/sQ5Xbd5jicAyKf9buMGxK32+A+EXqYbfS1wGt2JrRS22xZRo?= =?us-ascii?Q?2RFaNdyt13e67nJpmE1Q3sUfjZryOronBck6m6ba6720YB06O0LE0GrKgwXj?= =?us-ascii?Q?A7bhUGBT9qHH0ecAkE2G0smo7r0qnF/2F2iKR1qniXVF3l7wNoCxn/Sc1YaX?= =?us-ascii?Q?Umbhl4bulcTJM/PiiJIb1CR82SA7L1JA2QQrz+ScNjd4x1n5T2DHemp3saFh?= =?us-ascii?Q?N2xM0quaCul06zh3+b6nQwbKWci5yxEoaqXxEdNoYzk1TxcYjC6xoM8IZIOk?= =?us-ascii?Q?O9cK3/4aEMjAP2qwPQYBCuoQrSQy5SMTeCRuGAwGqzQBFyUKncOSo45Vt4oC?= =?us-ascii?Q?R6IxhpYKyeGW9OiRHJQLph18qUNmurqM/5eam+DHwlUhpYk8nLU+0Myqutw7?= =?us-ascii?Q?GDLRFfcmV9CmhqcpHzVw3frao7F00ofqdNshP4Qj6WNhFCnrWWSorCzkFR3i?= =?us-ascii?Q?60x1ursUG5wmQZu1Q+L02dlodD4kBet7hI4x4JRS+d9F5Q+1EKpH+WvyG8Hv?= =?us-ascii?Q?H6ZdfQOPR49ieogRzC/YbyLOYmcaRmwiST/g8Rzo+b4xncyct/3oz4ZlldT6?= =?us-ascii?Q?yRFrl6Bd+Hi2a0aAgz1V/IEU4YeUbf4SKNfNLVFqSIJXQurrRS57IktU1Qrh?= =?us-ascii?Q?09goyCh+SPm8ihpRQym+alAVTKWnGLYERP6TvRcmYpeoPB6zsRbCNTWO8RvQ?= =?us-ascii?Q?UIB8OIutpbjcwevtWgRDkCml0VPw=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0701MB1726; 6:lerIunULl+F1Z6oqdBdHGBa9RNbaSw6lJq5Rhbwk2/7jpv0OGPPEn+DWRArehbxUY17naDDEGk+DsbfPbW5TgsUREc42ekn10CWJJVF96+QxFrn1Woo5ufyHK4k393WYh2gL39vpmYeDKGFuepmuoQkyGVQ1Q+KMGk3nuXgEzgak3SZVTHE1/AEC7ftAS2onqhbehVhAX5UjeuKB+KH1wjR187pzIaq6zWqWwOnVjLaQSt30CTIrQ2wx6wLTE+/MtjTR8PSog7WV4tRS5PEDDf0c1PQAHCysHTJs7yonuTthD5asXSEbXWUOeyr/eUt62u0jsYbjBe+k3eIim/JgszXBxG5+0nVVamleH+P66fhvvVuCEgh1q74sXuDvHfLBWeHy+7QVj2KOGWwzDIjSbEq2uQRW28X64EvXYWO4p70=; 5:hviFklerMg8CjOuX/01xQVTW132GaizTIB253OCutibsSky/49g8fEi/TUELnolS5Vs23NMkUVf6i0xpbm5EsrW+D4NTmPF3Veczal9HInSdJUUDHFmnnvW4hEe0gyJ7o3AcQxdkbMYruWgRMAhSww==; 24:x5uSX/RuHKHEsVH/osQrAFkHuJ7H5l9cGN1kQ0zv5UBqMIrBDay8LRQBzVtK117A3M51kOD7sOKqawKF0k0r88dUaxeVAWlC8hZVwjbwV5g= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR0701MB1726; 7:mIwYyQtKSkbfCNBCVKKbB7rd0G1psCxafcNLDl59jqB5SP3wRyQnrGaHV1XoDTPZcGFi6jCU6iqa8O65CD5amZa7WOyZHhS+UU82nDRUgKmzJIhc/US3uvmMBzGRj55+/vzM4bLNvy8kj4/FIYAmRiWMY7RuKCQEJjqJfNtJ8znb6YBC5iVlWnG/M+bDUox7X8EnuBXh1EHL0u+lkOUJYQO2t5gqe5YzHtGp/2BkjKlVbx243rehtyxMtZ+wZ+BU/jDQmDtz53YU3m4W7wch3mLRWUICWSs0xG5Vj8BxdrW6kXBB3sVSnRolMPl4ChbPllQBSPJTO47GyZIYob1zMj4w0RGFwxNd2LVeXCpk99pzIpmw5CIZkr+DWdlwvk1N4paNBG5lp88B+s3YAfL9AEqc+qvusXM7u5bx/Xq3QqKheac9IzRnysM2qVwV51IJKPh8jlNknk5XHYXSycV6V8Zm4n+4KuCOczXs5GzSKTg7mR6N1CT0jmH/uNBVYr1I16Q48qjOisgwpxlDurNw5uO3gb5Gycv3hEUkGgum49pKtTqRzeVXvWM30nQHkplg X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jan 2017 14:32:45.8712 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0701MB1726 Subject: Re: [dpdk-dev] [PATCH v2] mempool: Introduce _populate_mz_range api X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 14:32:49 -0000 Hi Olivier, Reply inline. On Tue, Jan 31, 2017 at 11:31:51AM +0100, Olivier Matz wrote: > Hi Santosh, > > I guess this patch is targeted for 17.05, right? > Yes. > Please see some other comments below. > > On Fri, 20 Jan 2017 20:43:41 +0530, > wrote: > > From: Santosh Shukla > > > > HW pool manager e.g. Cavium SoC need s/w to program start and > > end address of pool. Currently there is no such api in ext-mempool. > > Today, the mempool objects are not necessarily contiguous in > virtual or physical memory. The only assumption that can be made is > that each object is contiguous (virtually and physically). If the flag > MEMPOOL_F_NO_PHYS_CONTIG is passed, each object is assured to be > contiguous virtually. > Some clarification: IIUC then pa/va addr for each hugepage (aka mz) is contiguous but no gaurantee of contiguity across the hugepages (aka muli-mzs), Right? If above said is correct then case like pool start addr in one mz and end addr is on another mz is a problem scenario. Correct? That said then ext-mempool drivers will get affected in such cases. > > So introducing _populate_mz_range API which will let HW(pool manager) > > know about hugepage mapped virtual start and end address. > > rte_mempool_ops_populate_mz_range() looks a bit long. What about > rte_mempool_ops_populate() instead? Ok. > > diff --git a/lib/librte_mempool/rte_mempool.c > > b/lib/librte_mempool/rte_mempool.c index 1c2aed8..9a39f5c 100644 > > --- a/lib/librte_mempool/rte_mempool.c > > +++ b/lib/librte_mempool/rte_mempool.c > > @@ -568,6 +568,10 @@ static unsigned optimize_object_size(unsigned > > obj_size) else > > paddr = mz->phys_addr; > > > > + /* Populate mz range */ > > + if ((mp->flags & MEMPOOL_F_POOL_CREATED) == 0) > > + rte_mempool_ops_populate_mz_range(mp, mz); > > + > > if (rte_eal_has_hugepages() > > Given what I've said above, I think the populate() callback should be > in rte_mempool_populate_phys() instead of > rte_mempool_populate_default(). It would be called for each contiguous > zone. > Ok. > > --- a/lib/librte_mempool/rte_mempool.h > > +++ b/lib/librte_mempool/rte_mempool.h > > @@ -387,6 +387,12 @@ typedef int (*rte_mempool_dequeue_t)(struct > > rte_mempool *mp, */ > > typedef unsigned (*rte_mempool_get_count)(const struct rte_mempool > > *mp); +/** > > + * Set the memzone va/pa addr range and len in the external pool. > > + */ > > +typedef void (*rte_mempool_populate_mz_range_t)(struct rte_mempool > > *mp, > > + const struct rte_memzone *mz); > > + > > And this API would be: > typedef void (*rte_mempool_populate_t)(struct rte_mempool *mp, > char *vaddr, phys_addr_t paddr, size_t len) > > > If your hw absolutly needs a contiguous memory, a solution could be: > > - add a new flag MEMPOOL_F_CONTIG (maybe a better nale could be > found) saying that all the mempool objects must be contiguous. > - add the ops_populate() callback in rte_mempool_populate_phys(), as > suggested above > > Then: > > /* create an empty mempool */ > rte_mempool_create_empty(...); > > /* set the handler: > * in the ext handler, the mempool flags are updated with > * MEMPOOL_F_CONTIG > */ > rte_mempool_set_ops_byname(..., "my_hardware"); > You mean, ext handler will set mempool flag using 'pool_config' param; somethng like rte_mempool_ops_by_name(..., "my_hardware" , MEMPOOL_F_CONTIG); ? > /* if MEMPOOL_F_CONTIG is set, all populate() functions should ensure > * that there is only one contiguous zone > */ > rte_mempool_populate_default(...); > I am not too sure about scope of MEMPOOL_F_CONTIG. How MEMPOOL_F_CONTIG flag {setted by application/ driver by calling rte_mempool_create(..., flag)} can make sure only one contiguous zone? Like to understand from you. In my understanding: rte_mempool_populate_default() will request for memzone based on mp->size value; And if mp->size more than one hugepage_sz{i.e. one mz request not enough} then it will request more hugepages{ i.e. more mz request},. So IIIU then contiguity not gauranteed. > Regards, > Olivier