From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id D1C622BF2; Mon, 2 Apr 2018 12:02:38 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Apr 2018 03:02:37 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,395,1517904000"; d="scan'208";a="187948284" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.252.35.99]) ([10.252.35.99]) by orsmga004.jf.intel.com with ESMTP; 02 Apr 2018 03:02:35 -0700 To: santosh , dev@dpdk.org Cc: thomas@monjalon.net, stable@dpdk.org References: <37c2e329be49799fae8328e4dd93e5c95da3d326.1522585461.git.anatoly.burakov@intel.com> <4868d2ccaffa1ae0d793fe10623d3e303a514ccf.1522585461.git.anatoly.burakov@intel.com> <21509d3e-fc7f-bf00-ee7c-fa20b41ac228@caviumnetworks.com> From: "Burakov, Anatoly" Message-ID: Date: Mon, 2 Apr 2018 11:02:34 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <21509d3e-fc7f-bf00-ee7c-fa20b41ac228@caviumnetworks.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 2/4] eal: do not use physical addresses in IOVA as VA mode 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: Mon, 02 Apr 2018 10:02:39 -0000 On 02-Apr-18 6:35 AM, santosh wrote: > > On Sunday 01 April 2018 05:56 PM, Anatoly Burakov wrote: >> We already use VA addresses for IOVA purposes everywhere if we're in >> RTE_IOVA_VA mode: >> 1) rte_malloc_virt2phy()/rte_malloc_virt2iova() always return VA addresses >> 2) Because of 1), memzone's IOVA is set to VA address on reserve >> 3) Because of 2), mempool's IOVA addresses are set to VA addresses >> >> The only place where actual physical addresses are stored is in memsegs at >> init time, but we're not using them anywhere, and there is no external API >> to get those addresses (aside from manually iterating through memsegs), nor >> should anyone care about them in RTE_IOVA_VA mode. >> >> So, fix EAL initialization to allocate VA-contiguous segments at the start >> without regard for physical addresses (as if they weren't available), and >> use VA to set final IOVA addresses for all pages. >> >> Fixes: 62196f4e0941 ("mem: rename address mapping function to IOVA") >> Cc: thomas@monjalon.net >> Cc: stable@dpdk.org >> >> Signed-off-by: Anatoly Burakov >> --- >> lib/librte_eal/linuxapp/eal/eal_memory.c | 6 +++++- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> >> diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c b/lib/librte_eal/linuxapp/eal/eal_memory.c >> index 38853b7..ecf375b 100644 >> --- a/lib/librte_eal/linuxapp/eal/eal_memory.c >> +++ b/lib/librte_eal/linuxapp/eal/eal_memory.c >> @@ -473,6 +473,9 @@ map_all_hugepages(struct hugepage_file *hugepg_tbl, struct hugepage_info *hpi, >> hugepg_tbl[i].orig_va = virtaddr; >> } >> else { >> + /* rewrite physical addresses in IOVA as VA mode */ >> + if (rte_eal_iova_mode() == RTE_IOVA_VA) >> + hugepg_tbl[i].physaddr = (uintptr_t)virtaddr; >> hugepg_tbl[i].final_va = virtaddr; >> } >> >> @@ -1091,7 +1094,8 @@ rte_eal_hugepage_init(void) >> continue; >> } >> >> - if (phys_addrs_available) { >> + if (phys_addrs_available && >> + rte_eal_iova_mode() != RTE_IOVA_VA) { > > Also can be done like below: > if (phys_addrs_available) > /* find physical addresses for each hugepage */ > if (find_iovaaddrs(&tmp_hp[hp_offset], hpi) < 0) { > > such that; > find_iovaaddrs() --> rte_mem_virt2iova(). > > That way avoid iova check in above if loop. > does that make sense? > Thanks. > [...] > Hi, That was the initial implementation, however it doesn't work because we do two mappings, original and final, and physical addresses are found during original mappings (meaning, their VA's will be all over the place). We are interested in final VA as IOVA (after all of the sorting and figuring out which segments are contiguous), hence the current implementation. -- Thanks, Anatoly