From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f196.google.com (mail-wr0-f196.google.com [209.85.128.196]) by dpdk.org (Postfix) with ESMTP id C375A2C8 for ; Mon, 3 Jul 2017 12:04:38 +0200 (CEST) Received: by mail-wr0-f196.google.com with SMTP id k67so44155708wrc.1 for ; Mon, 03 Jul 2017 03:04:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=9O9/JLQwGvuX2Nqj6aSUCLTaKSuzLgjKHXAt6mRXQKA=; b=gaeJaZmb4hBWBZrFZsRKpYp6UUrHSdp21limQBegcfK8ch57X5QdN2eRF9LoWE2xAJ oU2+ChdCj7exxJL4bT8DA1gTf0AP4jyGVuiltcrtEl0u54JlIr35bq7AJ8UlXijkiWIn pFEQlGKPcLMr7fJrb+b01rbljs9KV3fV3EDA3DKtR6G/We3jhOxDeT4oUFWlJ/AbTCyU Zdyd891H/ju26ygr0IlQZs0TM77XWulTNDtiQFTh86qVhhSTznepQpXtPVRY9V6kfwYS 3rEHCDOY0nuO9Cz+LSZWmI707x2ZiG+6iJdhCMg8w6f2ubRYQ07gbVijBTCJeVqPEzBF OudQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=9O9/JLQwGvuX2Nqj6aSUCLTaKSuzLgjKHXAt6mRXQKA=; b=cPioBaVMqdZF9XraWOfoLQBLXONpOofo6I83qOwshilKSdlDNdU7OCoBg7Zf3YyH1x oogEDcwwVpeeUyREGPSGn63U0tl3D+ajxmrbPblpYuMR9lnLbUoiyV0qLlUvFxdPAk7G AjGEy8bo2izQSBuQmEDU6HFbIzbXUG2QFDoodCjpT1pi+hjhIdANNcEI3BfglkDU7FS7 TH8GqPvq0pq5kHZ+1Wu7zDIbg/KFzoKrwPmzscUZFxWG72sTLh5hM0gEsf3dlcZTYygK 1zCIJ3gErAE8GhSNqKiRh13o2Gp6/2l7Eg35VikV4+lwSStrnQsINLaH4Nqd2T39At18 pv4A== X-Gm-Message-State: AKS2vOz8oLUvsflsKLT3YVEtxxkvzzBScFUmJZMFZlYbMRcKgeXhLC8l 4jn/rRnTvnsNKL4Ud2S4shht0dopBA== X-Received: by 10.223.143.77 with SMTP id p71mr31776948wrb.3.1499076278322; Mon, 03 Jul 2017 03:04:38 -0700 (PDT) MIME-Version: 1.0 Sender: jblunck@gmail.com Received: by 10.28.5.132 with HTTP; Mon, 3 Jul 2017 03:04:37 -0700 (PDT) In-Reply-To: <20170703102500.75cf7cd7@platinum> References: <138ba842ce615de6a6895f0ca74b5645aad48ad9.1496308649.git.gaetan.rivet@6wind.com> <20170703102500.75cf7cd7@platinum> From: Jan Blunck Date: Mon, 3 Jul 2017 12:04:37 +0200 X-Google-Sender-Auth: O14WkRQZznhfs8LgUBXpWbAEi8k Message-ID: To: Olivier Matz Cc: Gaetan Rivet , dev Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH 1/8] eal: expose rte_eal_using_phys_addrs 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: Mon, 03 Jul 2017 10:04:39 -0000 On Mon, Jul 3, 2017 at 10:25 AM, Olivier Matz wrote: > Hi, > > On Fri, 30 Jun 2017 21:05:47 +0200, Jan Blunck wrote: >> On Thu, Jun 1, 2017 at 12:14 PM, Gaetan Rivet wrote: >> > This function was previously private to the EAL layer. >> > Other subsystems requires it, such as the PCI bus. >> > >> > This function is only exposed for linuxapps. >> > >> > In order not to force other components to include stdbool, which is >> > incompatible with several NIC drivers, the return type has >> > been changed from bool to int. >> > >> > Signed-off-by: Gaetan Rivet >> > --- >> > lib/librte_eal/common/eal_private.h | 11 ----- >> > lib/librte_eal/linuxapp/eal/Makefile | 2 + >> > lib/librte_eal/linuxapp/eal/eal_memory.c | 3 +- >> > lib/librte_eal/linuxapp/eal/eal_pci.c | 1 + >> > lib/librte_eal/linuxapp/eal/rte_eal_version.map | 1 + >> > lib/librte_eal/linuxapp/eal/rte_memory_linux.h | 64 +++++++++++++++++++++++++ >> > 6 files changed, 70 insertions(+), 12 deletions(-) >> > create mode 100644 lib/librte_eal/linuxapp/eal/rte_memory_linux.h >> > >> > diff --git a/lib/librte_eal/common/eal_private.h b/lib/librte_eal/common/eal_private.h >> > index 6d2206a..b7e4cc6 100644 >> > --- a/lib/librte_eal/common/eal_private.h >> > +++ b/lib/librte_eal/common/eal_private.h >> > @@ -327,17 +327,6 @@ int rte_eal_hugepage_init(void); >> > */ >> > int rte_eal_hugepage_attach(void); >> > >> > -/** >> > - * Returns true if the system is able to obtain >> > - * physical addresses. Return false if using DMA >> > - * addresses through an IOMMU. >> > - * >> > - * Drivers based on uio will not load unless physical >> > - * addresses are obtainable. It is only possible to get >> > - * physical addresses when running as a privileged user. >> > - */ >> > -bool rte_eal_using_phys_addrs(void); >> > - >> > /* >> > * Validate a bus name. >> > * >> > diff --git a/lib/librte_eal/linuxapp/eal/Makefile b/lib/librte_eal/linuxapp/eal/Makefile >> > index 640afd0..530e286 100644 >> > --- a/lib/librte_eal/linuxapp/eal/Makefile >> > +++ b/lib/librte_eal/linuxapp/eal/Makefile >> > @@ -131,4 +131,6 @@ INC := rte_interrupts.h rte_kni_common.h rte_dom0_common.h >> > SYMLINK-$(CONFIG_RTE_EXEC_ENV_LINUXAPP)-include/exec-env := \ >> > $(addprefix include/exec-env/,$(INC)) >> > >> > +SYMLINK-$(CONFIG_RTE_EXEC_ENV_LINUXAPP)-include += rte_memory_linux.h >> > + >> > include $(RTE_SDK)/mk/rte.lib.mk >> > diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c b/lib/librte_eal/linuxapp/eal/eal_memory.c >> > index ebe0683..072bfe4 100644 >> > --- a/lib/librte_eal/linuxapp/eal/eal_memory.c >> > +++ b/lib/librte_eal/linuxapp/eal/eal_memory.c >> > @@ -99,6 +99,7 @@ >> > #include "eal_internal_cfg.h" >> > #include "eal_filesystem.h" >> > #include "eal_hugepages.h" >> > +#include "rte_memory_linux.h" >> > >> > #define PFN_MASK_SIZE 8 >> > >> > @@ -1472,7 +1473,7 @@ rte_eal_hugepage_attach(void) >> > return -1; >> > } >> > >> > -bool >> > +int >> > rte_eal_using_phys_addrs(void) >> > { >> > return phys_addrs_available; >> > diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c b/lib/librte_eal/linuxapp/eal/eal_pci.c >> > index 595622b..9d5b051 100644 >> > --- a/lib/librte_eal/linuxapp/eal/eal_pci.c >> > +++ b/lib/librte_eal/linuxapp/eal/eal_pci.c >> > @@ -45,6 +45,7 @@ >> > #include "eal_filesystem.h" >> > #include "eal_private.h" >> > #include "eal_pci_init.h" >> > +#include "rte_memory_linux.h" >> > >> > /** >> > * @file >> > diff --git a/lib/librte_eal/linuxapp/eal/rte_eal_version.map b/lib/librte_eal/linuxapp/eal/rte_eal_version.map >> > index a5127d6..8916520 100644 >> > --- a/lib/librte_eal/linuxapp/eal/rte_eal_version.map >> > +++ b/lib/librte_eal/linuxapp/eal/rte_eal_version.map >> > @@ -207,5 +207,6 @@ DPDK_17.08 { >> > >> > rte_bus_from_name; >> > rte_bus_from_dev; >> > + rte_eal_using_phys_addrs; >> >> Is this only for the UIO mapping? Would it be better to let UIO skip >> (and warn?) over RTE_BAD_PHYS_ADDR mappings? That way we don't need >> this export and its probably more resilient to bad mappings. >> >> Thoughts? Olivier? > > From what I see, rte_eal_using_phys_addrs() is used by: > > rte_eal_pci_map_device(struct rte_pci_device *dev) > { > ... > case RTE_KDRV_IGB_UIO: > case RTE_KDRV_UIO_GENERIC: > if (rte_eal_using_phys_addrs()) { > /* map resources for devices that use uio */ > ret = pci_uio_map_resource(dev); > } > > > Looking at pci_uio_map_resource() and its callees, I'm not sure it's > easy to replace it something else. The functions that would return > RTE_BAD_PHYS_ADDR (virt2phy-like) are not called there. > Right, so why is it there in the first place? From what I can see the code should work just fine even in cases we don't have physical addresses available. Shouldn't the code actually requiring physical addresses (e.g. RX queue setup, ...) check for this instead?