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 948EFA04DD; Tue, 26 Nov 2019 13:54:58 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 976622B88; Tue, 26 Nov 2019 13:54:57 +0100 (CET) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 955BD2A5D for ; Tue, 26 Nov 2019 13:54:55 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Nov 2019 04:54:54 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,245,1571727600"; d="scan'208";a="233737159" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.237.220.92]) ([10.237.220.92]) by fmsmga004.fm.intel.com with ESMTP; 26 Nov 2019 04:54:53 -0800 To: Thomas Monjalon Cc: dev@dpdk.org, Olivier Matz References: <9ac0f4b480cec8cbe8a9910a68f9d564641c2f41.1573740779.git.anatoly.burakov@intel.com> <20191118131421.GD8680@platinum> <6968599.34HkkUUQbD@xps> From: "Burakov, Anatoly" Message-ID: <6c07652f-8737-ba67-26ca-3646e86e3c3f@intel.com> Date: Tue, 26 Nov 2019 12:54:52 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <6968599.34HkkUUQbD@xps> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] mem: clarify documentation for rte_mem_virt2iova 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" On 25-Nov-19 11:32 PM, Thomas Monjalon wrote: > 18/11/2019 14:14, Olivier Matz: >> On Thu, Nov 14, 2019 at 02:13:06PM +0000, Anatoly Burakov wrote: >>> It may not be immediately clear that rte_mem_virt2iova does not actually >>> check the internal memseg table, and will instead either return VA (in >>> IOVA as VA mode), or will fall back to kernel page table walk (in IOVA >>> as PA mode). >>> >>> Add a note to API documentation indicating the above. >>> >>> Signed-off-by: Anatoly Burakov >> >> Reviewed-by: Olivier Matz > > Applied, thanks > There are multiple places where this function is used, and its use is not compatible with external memory. I think we should replace all usages of this function to rte_mem_virt2memseg(), and rename this function, because its actual intended usage is *not* VA->IOVA translation, but instead is akin to figuring out what IOVA address *should* be with current IOVA settings, regardless of any internal page table and current VFIO mappings. -- Thanks, Anatoly