From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 8A37DA0096 for ; Mon, 3 Jun 2019 12:49:11 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A17141B947; Mon, 3 Jun 2019 12:49:10 +0200 (CEST) Received: from mail-vs1-f51.google.com (mail-vs1-f51.google.com [209.85.217.51]) by dpdk.org (Postfix) with ESMTP id BE22F1B945 for ; Mon, 3 Jun 2019 12:49:09 +0200 (CEST) Received: by mail-vs1-f51.google.com with SMTP id v129so1672841vsb.11 for ; Mon, 03 Jun 2019 03:49:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iumGZBm2Le7y4Vy6kVxcQAyj54xD6/rX/HofS/g1YZc=; b=Tys14FH/56ZBBVpw/77AzkZroBxE4b5/MDzkAi2KeTnDx4evNgXzIQ8dzc7ykoAX0J SLvt3nzxG35Ci22octAdgjfvEKBx5SKy9ToDdcMIL6W3jitLUyu9cEsIwVpwfQwsSIxc TyiIRK/N9R8/pwP5wm7J5f+FeZnjDjzqtHOe49BGJCMgTM0EdI/vC2Xd8mddBn6yDKfc qOzP/KYhFeVCj5Vp3Tr2A9of2qKbq1oq7xOPRBcbxRxxz+hOb16FQbbJ5Y+CqSujpq5e Xvs3QdE0rKS4zfRaK8/OrxeDsAAX+IUF4O+/avgamh42B8XZ6ZMMqrm4WuQu7KwAop7T sE4w== X-Gm-Message-State: APjAAAWZLW+kEMoeC/W2yZLWXEUYA9A987o//xhzoQxYl1YF/JuFuhdY HM9/Hv7sDRXzXjwXk+O3Q5xfHpIR4xsSyyZigPQJcw== X-Google-Smtp-Source: APXvYqypiD30KfuRT/qehXzce/8PCsSiVf6KxEBV6GaZXcauZ9xo9c6lgaoN9K+OzuwpbbAtsAeY6LxYh/gaFt47F3U= X-Received: by 2002:a67:e9ca:: with SMTP id q10mr529734vso.105.1559558949041; Mon, 03 Jun 2019 03:49:09 -0700 (PDT) MIME-Version: 1.0 References: <20190530174819.1160221-1-benjamin.walker@intel.com> In-Reply-To: <20190530174819.1160221-1-benjamin.walker@intel.com> From: David Marchand Date: Mon, 3 Jun 2019 12:48:58 +0200 Message-ID: To: Ben Walker , Jerin Jacob Kollanukkaran Cc: dev , "Burakov, Anatoly" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] eal/pci: Improve automatic selection of IOVA mode 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" Hello, On Thu, May 30, 2019 at 7:48 PM Ben Walker wrote: > In SPDK, not all drivers are registered with DPDK at start up time. > Previously, that meant DPDK always chose to set itself up in IOVA_PA > mode. Instead, when the correct iova choice is unclear based on the > devices and drivers known to DPDK at start up time, use other heuristics > (such as whether /proc/self/pagemap is accessible) to make a better > choice. > > This enables SPDK to run as an unprivileged user again without requiring > users to explicitly set the iova mode on the command line. > > Interesting, I got a bz on something similar the day you sent this patchset ;-) - When a dpdk process is started, either it has access to physical addresses or not, and this won't change for the rest of its life. Your fix on defaulting to VA based on a rte_eal_using_phys_addrs() check makes sense to me. It is the most encountered situation when running ovs as non root on recent kernels. - However, I fail to see the need for all of this detection code wrt drivers and devices. On one side of the equation, when dpdk starts, it checks physical address availability. On the other side of the equation, we have the drivers that will be invoked when probing devices (either at dpdk init, or when hotplugging a device). At this point, the probing call should check the driver requirement wrt to the kernel driver the device is attached to. If this requirement is not fulfilled, then the probing fails. - This leaves the --iova-va forcing option. Why do we need it? If we don't have access to physical addresses, no choice but run in VA mode. If we have access to physical addresses, the only case would be that you want to downgrade from PA to VA. But well, your process can still access it, not sure what the benefit is. Jerin, I can see in the history you worked on this. What did I miss? Is there something wrong with dropping the detection code? -- David Marchand