From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 779C9A00E6 for ; Thu, 8 Aug 2019 09:31:55 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5C59B231E; Thu, 8 Aug 2019 09:31:54 +0200 (CEST) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) by dpdk.org (Postfix) with ESMTP id EED192082 for ; Thu, 8 Aug 2019 09:31:52 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 1D357147D; Thu, 8 Aug 2019 03:31:52 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 08 Aug 2019 03:31:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=RVaW1x3BL5DLRHSb/rbtINJQ+SW7WMoKAwGcbqPqwfY=; b=EwLk65iUYums wj4pitSoxE/RPKLjxgcr4FUZNq3h7oIbWpHHoSvtkrL33QO15oRdTP+HWGhTDOHJ nz5fEL9hosZxukpcvLvGLlglUSN0gy595ZPzfAeI6o80dVIBjrxzG6y6Z9rSrMvH 9pnDM6C019PcXljAux+SNa2bVI3IlWk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=RVaW1x3BL5DLRHSb/rbtINJQ+SW7WMoKAwGcbqPqw fY=; b=JOUhrWmSeBqnIenLevPU9iCYmSUu04j4IWDyZAX0ruqFF2dCpf7gFEjYU RkAOQ0NalZuBknX6u7l/+0EeKkJ6ruyTwawtI6XR8G/2THFBGHk7jBrEy2CDoYTC Q8w5Se6MD3t8GM0QeUxcwxhax61uowKflrBkVsSip7ILLyoDsaW6SNrbbv0wfKlk A9lke8vrDsmlq/qkTedh4HVADLPjYoa/gCQwljPOLqyws+F34Vj98t1mmw9w7wp8 IgAcGsq1v3daqFfyRzVbAVykrDBP1SdIqNCWq+q/c1B3jTcn1+Ea+XYff9Raz/su QedHjDAoXQ/e7OFIjP6QtPP4oXPaQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddruddugedgleegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeelfedriedrudegledruddugeenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhm rghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from xps.localnet (114.149.6.93.rev.sfr.net [93.6.149.114]) by mail.messagingengine.com (Postfix) with ESMTPA id AAFA780064; Thu, 8 Aug 2019 03:31:48 -0400 (EDT) From: Thomas Monjalon To: Hemant Agrawal , Gagandeep Singh Cc: dev@dpdk.org, David Marchand , "Burakov, Anatoly" , Olivier Matz , Andrew Rybchenko , Nipun Gupta , honnappa.nagarahalli@arm.com, Steve Capper , jerinj@marvell.com, bruce.richardson@intel.com, gavin.hu@arm.com, konstantin.ananyev@intel.com, drc@linux.vnet.ibm.com Date: Thu, 08 Aug 2019 09:31:47 +0200 Message-ID: <15982978.NnXy4IA2Yx@xps> In-Reply-To: References: <20190807101204.21614-1-g.singh@nxp.com> <52183700.OczlixnxyG@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] eal: change max hugepage sizes to 4 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 07/08/2019 15:28, Hemant Agrawal: > HI Thomas, > > > > > DPDK currently is supporting maximum 3 hugepage, sizes whereas > > > > system can support more than this e.g. > > > > 64K, 2M, 32M and 1G. > > > > > > You can mention ARM platform here, and that this issue starts with > > > kernel 5.2 (and I would try to mention this in the title as well). > > > This is better than an annotation that will be lost. > > > > > > > > > > Having these four hugepage sizes available to use by DPDK, which is > > > > valid in case of '--in-memory' EAL option or using 4 separate mount > > > > points for each hugepage size; > > > > hugepage_info_init() API reports an error. > > > > > > Can you describe what is the impact from a user point of view rather > > > than mentioning this internal function? > > > > Yes please, we need to understand how much it is critical. > > Should we Cc stable@dpdk.org for backport? > > Should it be merged at the last minute in 19.08? > > VPP usages in-memory option. So, VPP on ARM with kernel 5.2 wont' work without this patch. Do you want to send a v2 with a better explanation? I would suggest to restrict the change to Arm only with an ifdef, in order to limit the risk for this release. We can think about a dynamic hugepage scan in the next release.