From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 0068AFEB for ; Tue, 30 Oct 2018 11:25:48 +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 fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Oct 2018 03:25:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,444,1534834800"; d="scan'208";a="103734472" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.237.220.72]) ([10.237.220.72]) by fmsmga001.fm.intel.com with ESMTP; 30 Oct 2018 03:25:43 -0700 To: Thomas Monjalon , Darek Stojaczyk Cc: dev@dpdk.org, Santosh Shukla , Hemant Agrawal , Jerin Jacob , Maxime Coquelin , Chas Williams , alejandro.lucero@netronome.com, arybchenko@solarflare.com, ferruh.yigit@intel.com, bruce.richardson@intel.com References: <20180907154703.83316-1-dariusz.stojaczyk@intel.com> <20180907155843.96465-1-dariusz.stojaczyk@intel.com> <2118758.mfmA9bi2Cz@xps> From: "Burakov, Anatoly" Message-ID: <7155e851-6d60-83d7-a095-86956d2ac2bc@intel.com> Date: Tue, 30 Oct 2018 10:25:42 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <2118758.mfmA9bi2Cz@xps> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2] eal/bus: use RTE_IOVA_PA only if phys addresses are available 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: Tue, 30 Oct 2018 10:25:49 -0000 On 28-Oct-18 11:11 PM, Thomas Monjalon wrote: > 17/09/2018 12:33, Burakov, Anatoly: >> On 07-Sep-18 4:58 PM, Darek Stojaczyk wrote: >>> When neither RTE_IOVA_VA nor RTE_IOVA_PA was explicitly >>> requested, DPDK would currently fallback to the default >>> RTE_IOVA_PA mode and possibly encounter a failure later >>> on if running as a non-priviledged user. Attempting to >>> use RTE_IOVA_VA if no phys addresses are available may >>> help in this case. >>> >>> Signed-off-by: Darek Stojaczyk >>> --- >>> Changes since v1: >>> * added a missing rte_memory.h include >>> >>> lib/librte_eal/common/eal_common_bus.c | 19 +++++++++++++++---- >>> 1 file changed, 15 insertions(+), 4 deletions(-) >>> >>> diff --git a/lib/librte_eal/common/eal_common_bus.c b/lib/librte_eal/common/eal_common_bus.c >>> index 0943851cc..68c581b8a 100644 >>> --- a/lib/librte_eal/common/eal_common_bus.c >>> +++ b/lib/librte_eal/common/eal_common_bus.c >>> @@ -37,6 +37,7 @@ >>> #include >>> #include >>> #include >>> +#include >>> >>> #include "eal_private.h" >>> >>> @@ -236,9 +237,19 @@ rte_bus_get_iommu_class(void) >>> mode |= bus->get_iommu_class(); >>> } >>> >>> - if (mode != RTE_IOVA_VA) { >>> - /* Use default IOVA mode */ >>> - mode = RTE_IOVA_PA; >>> + if (mode == RTE_IOVA_VA) >>> + return RTE_IOVA_VA; >>> + >>> + if (mode & RTE_IOVA_PA) { >>> + /* Not all buses support RTE_IOVA_VA, fallback to RTE_IOVA_PA */ >>> + return RTE_IOVA_PA; >>> + } >>> + >>> + if (rte_eal_using_phys_addrs()) { >>> + /* Default to RTE_IOVA_PA only if it's supported */ >>> + return RTE_IOVA_PA; >>> } >>> - return mode; >>> + >>> + /* Since RTE_IOVA_PA is unsupported, fallback to RTE_IOVA_VA */ >>> + return RTE_IOVA_VA; >>> } >>> >> >> This is a good change, however I think that this is too pessimistic. If >> i don't have any devices that explictly require IOVA_PA, i should be >> running in IOVA_VA mode. >> >> This of course doesn't take hotplug into account, so a command-line >> switch to force one or the other should also be available. >> >> For example, at startup, i might have devices bound to VFIO, so IOVA_VA >> mode is picked. However, even though at a time of startup none of the >> devices require physical addresses, i also know that i might later >> hotplug a device that requires IOVA_PA (leaving the question of hotplug >> brokenness aside for now...) - currently, this scenario will not work, >> as i will be forced to use IOVA_VA mode unless i happen to have a >> IOVA_PA device available at startup. >> >> Similarly, if i'm running DPDK as root but am only using virtual devices >> like pcap, i should be able to force DPDK into using VA addresses [*], >> yet currently i will be forced to use IOVA_PA if i don't *also* have a >> few devices bound exclusively to VFIO. >> >> [*] Do we have vdev devices that require IOVA_PA? I can't think of any... > > If running as root, what is the benefit of using virtual addresses? > Contiguous memory addresses is one that comes to mind. -- Thanks, Anatoly