From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id CA9E71B395 for ; Thu, 11 Oct 2018 12:26:08 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Oct 2018 03:26:07 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,368,1534834800"; d="scan'208";a="270419240" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.237.220.79]) ([10.237.220.79]) by fmsmga005.fm.intel.com with ESMTP; 11 Oct 2018 03:26:06 -0700 To: Alejandro Lucero , dariusz.stojaczyk@intel.com Cc: dev , Santosh Shukla , Hemant Agrawal , Jerin Jacob , Maxime Coquelin , chas3@att.com References: <20180907145340.79670-1-dariusz.stojaczyk@intel.com> From: "Burakov, Anatoly" Message-ID: <93d12b45-d0a9-ab28-5ead-c3424067a062@intel.com> Date: Thu, 11 Oct 2018 11:26:05 +0100 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] pci/linux: use RTE_IOVA_VA whenever possible 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: Thu, 11 Oct 2018 10:26:09 -0000 On 11-Oct-18 11:00 AM, Alejandro Lucero wrote: > On Fri, Sep 7, 2018 at 3:55 PM Darek Stojaczyk > wrote: > >> This allows DPDK to use RTE_IOVA_VA with VFIO/UIO-bound PCI >> devices present on the system, but not attached to any >> rte_pci_driver at the time of init. >> >> So far we used RTE_IOVA_VA whenever there was at least one >> device attached to a driver with an RTE_PCI_DRV_IOVA_AS_VA flag, >> meaning that other drivers which didn't explicitly report such >> flag could have been forced to work in RTE_IOVA_VA as well. >> > > This is the opposite. Just one device not being able to use IOVA VA makes > all to use IOVA PA. > > >> >> This patch makes the RTE_PCI_DRV_IOVA_AS_VA explicitly a hint. >> If it's set, but RTE_IOVA_VA cannot be used, then EAL will print >> a proper warning. >> >> Signed-off-by: Darek Stojaczyk >> --- >> drivers/bus/pci/linux/pci.c | 11 +++++------ >> 1 file changed, 5 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/pci.c >> index 04648ac93..961e24024 100644 >> --- a/drivers/bus/pci/linux/pci.c >> +++ b/drivers/bus/pci/linux/pci.c >> @@ -534,7 +534,7 @@ pci_one_device_bound_uio(void) >> * Any one of the device has iova as va >> */ >> static inline int >> -pci_one_device_has_iova_va(void) >> +pci_one_device_want_iova_va(void) >> { >> struct rte_pci_device *dev = NULL; >> struct rte_pci_driver *drv = NULL; >> @@ -635,7 +635,7 @@ rte_pci_get_iommu_class(void) >> { >> bool is_bound; >> bool is_vfio_noiommu_enabled = true; >> - bool has_iova_va; >> + bool want_iova_va; >> bool is_bound_uio; >> bool iommu_no_va; >> >> @@ -643,7 +643,7 @@ rte_pci_get_iommu_class(void) >> if (!is_bound) >> return RTE_IOVA_DC; >> >> - has_iova_va = pci_one_device_has_iova_va(); >> + want_iova_va = pci_one_device_want_iova_va(); >> is_bound_uio = pci_one_device_bound_uio(); >> iommu_no_va = !pci_devices_iommu_support_va(); >> #ifdef VFIO_PRESENT >> @@ -651,11 +651,10 @@ rte_pci_get_iommu_class(void) >> true : false; >> #endif >> >> - if (has_iova_va && !is_bound_uio && !is_vfio_noiommu_enabled && >> - !iommu_no_va) >> + if (!is_bound_uio && !is_vfio_noiommu_enabled && !iommu_no_va) >> return RTE_IOVA_VA; >> > > This is wrong. A device not able to work with IOVA VA will fail. > > >> >> - if (has_iova_va) { >> + if (want_iova_va) { >> RTE_LOG(WARNING, EAL, "Some devices want iova as va but pa >> will be used because.. "); >> if (is_vfio_noiommu_enabled) >> RTE_LOG(WARNING, EAL, "vfio-noiommu mode >> configured\n"); >> -- >> 2.17.1 >> >> > For these cases, i think the explicit IOVA mode on command line should work better. If the device has not reported IOVA as VA capability, it is to be assumed unsupported. -- Thanks, Anatoly