From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 5FFC22965 for ; Sun, 28 Oct 2018 19:56:05 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id CDED421EA7; Sun, 28 Oct 2018 14:56:04 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 28 Oct 2018 14:56:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=I5D1ZKfx87kyJSTolb3TcnZ+GZY8TvPKBEMCyNGvsQU=; b=RJdcNKhnSi9u 5/9EJKXrnScmu2/SnHtl+MUmkRvf4fg252B7sU9wYuhnEuTyt8jz4l3xiuip2/C3 Cy8vq9rTFoRISMIQw37l2lXvDYRnXvfN3UcTFF1/b+rPLVz5AKHxTrMTGL4j8bKj AI/EF6JKRUoILbMXKcn61tuUnkiqwco= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=I5D1ZKfx87kyJSTolb3TcnZ+GZY8TvPKBEMCyNGvs QU=; b=HgZF0VQlAqy2L4E67SM/3yDwT1Nh+I6jkP5ol+/Gb9BJu+gursbuzlujw 8balSp2ORj21qsHacduiy6xCpNCt5CEOimBaft5spLDjsMmdGp8IMIfAxRT9aO+M mzN1GR8zy+QOMB0agOiJq+FBmz5dO8KlBNywALUzn7++UohvhuuYg79OVByA0R/h khpSyTG9JjRPszEOWrEGUrKwjx+fZAmxFe7kusppr1relvJMw+iPz81GGVXC3+oP 3pNu5A+jBvl/CrA0BizCrhgd4hQtYl4tpXT8tZchcJYr9gsS+2Gu/CX3WiRJHnQX Q01zy2+n38Udl9WRLb1NoBcHkyVrg== X-ME-Sender: X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 109D7E4430; Sun, 28 Oct 2018 14:56:01 -0400 (EDT) From: Thomas Monjalon To: "dariusz.stojaczyk@intel.com" Cc: dev@dpdk.org, Jerin Jacob , "Burakov, Anatoly" , Alejandro Lucero , "Shukla, Santosh" , Hemant Agrawal , Maxime Coquelin , "chas3@att.com" Date: Sun, 28 Oct 2018 19:56:07 +0100 Message-ID: <2254496.FTyVADVnFM@xps> In-Reply-To: <20181011104702.GA18152@jerin> References: <20180907145340.79670-1-dariusz.stojaczyk@intel.com> <93d12b45-d0a9-ab28-5ead-c3424067a062@intel.com> <20181011104702.GA18152@jerin> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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: Sun, 28 Oct 2018 18:56:05 -0000 11/10/2018 12:47, Jerin Jacob: > -----Original Message----- > > Date: Thu, 11 Oct 2018 11:26:05 +0100 > > From: "Burakov, Anatoly" > > To: Alejandro Lucero , > > dariusz.stojaczyk@intel.com > > CC: dev , Santosh Shukla , > > Hemant Agrawal , Jerin Jacob > > , Maxime Coquelin > > , chas3@att.com > > Subject: Re: [dpdk-dev] [PATCH] pci/linux: use RTE_IOVA_VA whenever possible > > User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 > > Thunderbird/52.9.1 > > > > > > 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. > > Yes. Patch marked as rejected