From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id E222CA0679 for ; Wed, 3 Apr 2019 19:22:26 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 114B01B508; Wed, 3 Apr 2019 19:22:26 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id 60A651B46B; Wed, 3 Apr 2019 19:22:24 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id F167E21B30; Wed, 3 Apr 2019 13:22:23 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 03 Apr 2019 13:22:23 -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=/XnviOoDWtxRuhFlpFMs2QcwMhfBMRrFCSuZuX601HU=; b=aNH8VD2VVSRS 3ACBTJUpfetJQQQI8DATOul2M//eDIINbKYOY0b7NTy7SiS1ET8QZUu7A5WWoXyH odumIa6WkVyC6H5Zn9wGqcG9ts4EkohMvphBG29fkyCBJW+Ez69hfDSp059Bkvqq kRxmuxsa8PGr4u+Eufa0idHEgJvXbuw= 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=fm2; bh=/XnviOoDWtxRuhFlpFMs2QcwMhfBMRrFCSuZuX601 HU=; b=aDZ1ay3/s+28knzSv5YsGLe+ipGLAgZNV5f0GFSclo/s3xEmo8WwIOIak J3YMqFM5lsb0FDb/oUCh2UBzS2NE0m8Cgmrc6AxkhcZkoTTuQU488W3GM766MOOC bepOOCahcfEZnRNmbHDh7TNt6uQikYFbD/0wiBI/FDnoz8xDf00Q/Zl9qnmQnvfH EYYnspLgp/C6pOpPMQPQ+HcaBz9WDLZriEMcjdjI58h+xRSj+6mGaDtSK6qaVrga j+dI/QUWTYjBL3Wkn1P5fy5Vrbm/3W+Xza0Hf2Mmm0ht3gL8WSkSdam18rHJ2+ab FUCHS4KvjVmlYFSsyjcRpCA0NsLCA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrtdefgdekieculddtuddrgedutddrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvden ucfhrhhomhepvfhhohhmrghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrg hlohhnrdhnvghtqeenucfkphepjeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhep mhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsth gvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 75A8110390; Wed, 3 Apr 2019 13:22:22 -0400 (EDT) From: Thomas Monjalon To: Shahaf Shuler Cc: stable@dpdk.org, Alejandro Lucero , "Burakov, Anatoly" , dev Date: Wed, 03 Apr 2019 19:22:21 +0200 Message-ID: <3135879.TiRoyuhVem@xps> In-Reply-To: References: <20190321202156.117496-1-shahafs@mellanox.com> <0ccaf7f1-e10c-de6a-1219-76ce6e76119f@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH v2] mem: limit use of address hint 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" Message-ID: <20190403172221.R_CkzDj8j-ITPFPFtNvn3RjR-snxl4FN_aP6onMIVVs@z> 02/04/2019 19:23, Alejandro Lucero: > On Tue, Apr 2, 2019 at 5:13 PM Burakov, Anatoly > wrote: > > On 31-Mar-19 9:43 AM, Shahaf Shuler wrote: > > > patch[1] added an address hint as starting address for 64 bit systems in > > > case an explicit base virtual address was not set by the user. > > > > > > The justification for such hint was to help devices that work in VA > > > mode and has a address range limitation to work smoothly with the eal > > > memory subsystem. > > > > > > While the base address value selected may work fine for the eal > > > initialization, it easily breaks when trying to register external memory > > > using rte_extmem_register API. > > > > > > Trying to register anonymous memory on RH x86_64 machine took several > > > minutes, during them the function eal_get_virtual_area repeatedly > > > scanned for a good VA candidate. > > > > > > The attempt to guess which VA address will be free for mapping will > > > always result in not portable, error prone code: > > > * different application may use different libraries along w/ DPDK. One > > > can never guess which library was called first and how much virtual > > > memory it consumed. > > > * external memory can be registered at any time in the application run > > > time. > > > > > > In order not to break the existing secondary process design, this patch > > > only limits the max number of tries that will be done with the > > > address hint. > > > When the number of tries exceeds the threshold the code > > > will use the suggested address from kernel. > > > > > > Fixes: 1df21702873d ("mem: use address hint for mapping hugepages") > > > Cc: stable@dpdk.org > > > Cc: alejandro.lucero@netronome.com > > > > > > [1] commit 1df21702873d ("mem: use address hint for mapping hugepages") > > > > > > Signed-off-by: Shahaf Shuler > > > --- > > > > > > On v2: > > > * instead of a complete remove of the hint limit the number of tries > > we allow. > > > --- > > > > LGTM > > > > Tested-by: Anatoly Burakov > > > > We can always increase the number of tries later :) > > > This is also fine for me. > If the map address is not within the supported range by a device with > addressing limitations, the device will not be used. > Not sure how this is likely to happen, but I guess if it is become a > problem, another solution should be implemented. > > Acked-by: Alejandro Lucero Applied, thanks