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 609CBA10DA for ; Fri, 2 Aug 2019 10:50:14 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E196D1C225; Fri, 2 Aug 2019 10:50:13 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id C55751C1F4 for ; Fri, 2 Aug 2019 10:50:12 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Aug 2019 01:50:11 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,337,1559545200"; d="scan'208";a="167173337" Received: from rlewando-mobl.ger.corp.intel.com (HELO [10.252.0.242]) ([10.252.0.242]) by orsmga008.jf.intel.com with ESMTP; 02 Aug 2019 01:50:09 -0700 To: David Marchand Cc: dev , Takeshi Yoshimura References: <20190731033523.2482-1-tyos@jp.ibm.com> From: "Burakov, Anatoly" Message-ID: Date: Fri, 2 Aug 2019 09:50:08 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.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] eal: forcing IOVA as PA in ppc 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 01-Aug-19 2:01 PM, David Marchand wrote: > Hello Anatoly, > > On Wed, Jul 31, 2019 at 5:36 AM Takeshi Yoshimura wrote: >> >> Commit b76fafb174d2 ("eal: fix IOVA mode selection as VA for PCI >> drivers") breaks ppc apps with no IOVA configs (or RTE_IOVA_DC) >> because of the inconsistency of user's request and the result of >> device capability for IOVA mode. I updated the code to force IOVA as >> PA in ppc as before because current ppc driver does not support VA >> mode. >> >> Theoretically, ppc can support VA mode, but I suspect that ppc with >> VA mode may have performance issues to create a big DMA window >> (VA often uses higher addresses than PA). So, I didn't change the >> code to check device capability in ppc. >> >> Signed-off-by: Takeshi Yoshimura >> --- >> lib/librte_eal/linux/eal/eal.c | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/lib/librte_eal/linux/eal/eal.c b/lib/librte_eal/linux/eal/eal.c >> index 946222ccd..db2dec922 100644 >> --- a/lib/librte_eal/linux/eal/eal.c >> +++ b/lib/librte_eal/linux/eal/eal.c >> @@ -1121,6 +1121,12 @@ rte_eal_init(int argc, char **argv) >> RTE_LOG(DEBUG, EAL, "KNI can not work since physical addresses are unavailable\n"); >> } >> } >> +#endif >> +#ifdef RTE_ARCH_PPC_64 >> + if (iova_mode == RTE_IOVA_VA) { >> + iova_mode = RTE_IOVA_PA; >> + RTE_LOG(WARNING, EAL, "Forcing IOVA as 'PA' because PPC uses PA mode.\n"); >> + } >> #endif >> rte_eal_get_configuration()->iova_mode = iova_mode; >> } else { >> -- >> 2.17.1 >> > > Afaiu, this problem is linked to a specific iommu implementation. > Does it make sense to introduce a check "iommu_support_va" in eal, a > bit like what we have in the pci bus ? > It probably does. Some platforms simply don't support VA mode (FreeBSD, for one), so that would be useful instead of hardcoding IOVA as PA/VA as defaults. -- Thanks, Anatoly