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 06EB5A067F for ; Thu, 28 Mar 2019 11:26:11 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C33401B0FF; Thu, 28 Mar 2019 11:26:10 +0100 (CET) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id C5DEF8E76; Thu, 28 Mar 2019 11:26:08 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Mar 2019 03:26:07 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,280,1549958400"; d="scan'208";a="159177449" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.237.220.103]) ([10.237.220.103]) by fmsmga001.fm.intel.com with ESMTP; 28 Mar 2019 03:26:06 -0700 To: Shahaf Shuler , "dev@dpdk.org" Cc: Thomas Monjalon , "stable@dpdk.org" , "alejandro.lucero@netronome.com" References: <20190321202156.117496-1-shahafs@mellanox.com> <0c3648af-015b-eddf-1967-becc670e42a2@intel.com> From: "Burakov, Anatoly" Message-ID: <0c3324f9-a550-5dc2-94aa-56099176f5ba@intel.com> Date: Thu, 28 Mar 2019 10:26:05 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format="flowed" Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] mem: don't use address hint for mapping unless requested 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: <20190328102605.0XrttoY6eswLxV06BE3nXwwgG-ifLPgvvgZiL9JkXOk@z> On 28-Mar-19 8:45 AM, Shahaf Shuler wrote: > Wednesday, March 27, 2019 1:50 PM, Burakov, Anatoly: >> Subject: Re: [PATCH] mem: don't use address hint for mapping unless >> requested >> >> On 21-Mar-19 8:21 PM, 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. >>> >>> This patch removes the default address hint and use the address >>> returned by mmap. >>> devices with address limitations should suggest to their users a >>> proper base-virtaddr (EAL arg) to use. >>> >>> 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 >>> --- >> >> I understand the motivation, however this will lower the reliability of >> secondary process initialization. > > Can you explain why? > It is very bad if we base the DPDK secondary process design on some predefined VA address base to be available. Our whole secondary process is "very bad design" in the first place, because it relies on address space duplication. This change was unrelated to it, but it has been shown that setting address hint to this value (or setting --base-virtaddr to the same address) improves success rate for secondary process initialization to the point where it doesn't even register in our internal bug tracker (whereas previously i did routinely get pings about secondary process init failing). This is just something we have to live with, and this change has been a net positive as far as reliability of secondary process initialization goes. > > Perhaps, the hinting could be improved by >> not trying to use the hint multiple times, but rather just once? I.e. >> if using hint succeeded - great, if not - try without one. Most of the time hint >> will work correctly, i think. >> >> -- >> Thanks, >> Anatoly -- Thanks, Anatoly