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 3DE0F4D3A for ; Mon, 29 Oct 2018 00:11:18 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9940221F8E; Sun, 28 Oct 2018 19:11:17 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 28 Oct 2018 19:11:17 -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=Xegy4JtRqSBOgbbprAOrXp6+Vd+HAAmUGgb14vzVu4s=; b=SzxJFMcmfTzJ kXTCjIXZvE2c/EGPEwGubK3yE85Y4I+RODz+ANegWbMzCpiPkic1psknNc9jmyqQ wH3mvoxZwURNJKd5DNRQF4sAqK6ij3J5vsPNt8R5F+fY2gQ2gJKjtW3KWyysGk2W gqDRWOBTSn42tDcqA9PIx6XDm2fpK64= 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=Xegy4JtRqSBOgbbprAOrXp6+Vd+HAAmUGgb14vzVu 4s=; b=dUXP7UHn0ctYHgpDlw4z1BSEJMajxvItu0FmOnxXXQcj8bwyftoA4uDjX oDhuoAhQJmKUZKlc8F3ws27mM9BK9tIIXfJjZEzaKHfRzBJusG+nkGlcItSJFhuC 4aYvEfdhfUHXWTRPS7mprypZGknnipxpcMeVv5lcTQS86IEmK0omWut90XI4PA8l 0RPzE6cMsthbXPEkGSX/zidwV+omQfEERjGSmPT04aUsWw5CxLsafPp1FYaOWqvR A5P+B2m7Q+Jyg/59GC/8f88xfaeE6vYe61lEyZzfZP1GILpl6VVbJ3xkDoqXjC9B nrKpbipTKQbbTVqMOcwqOMYGYIitQ== 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 5E6B6102DD; Sun, 28 Oct 2018 19:11:14 -0400 (EDT) From: Thomas Monjalon To: "Burakov, Anatoly" , 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 Date: Mon, 29 Oct 2018 00:11:20 +0100 Message-ID: <2118758.mfmA9bi2Cz@xps> In-Reply-To: References: <20180907154703.83316-1-dariusz.stojaczyk@intel.com> <20180907155843.96465-1-dariusz.stojaczyk@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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: Sun, 28 Oct 2018 23:11:18 -0000 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?