From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f170.google.com (mail-wr0-f170.google.com [209.85.128.170]) by dpdk.org (Postfix) with ESMTP id 3CD9D2C00 for ; Fri, 23 Jun 2017 10:11:59 +0200 (CEST) Received: by mail-wr0-f170.google.com with SMTP id r103so54987468wrb.0 for ; Fri, 23 Jun 2017 01:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=/dtoutPOEdCINHocW1rGR+2R83/wfd6HPoo9aE0vRoU=; b=FPTnsSs35IGGP4GvDCZJvx2eyZzblZlroPZnKCmXrQEcBfswJkKIjHcuQizoHSh758 gvk3F4Qu1/5tr5VXCw2fdU/WACu1qnbf/nXhL7Ao1bcILwRo5ohj+j4o1alTjsRMizLE Lr/0OzGfvbO1BvmL1MQCuHlssWcdxW6owquF+XidiL6GDt2vIyTl5blCPsuUFV2l8Rk/ 1n1xTHo1E3M1WKOlUPit47EJtLfE8/XCvSTm6ih1BqSztYz0Uq/pw1lUyzDsONsRhTq8 3wo90KNZFMoqESiCZS9Hjjagq7I47nKvcvkW4KhgnegKtWFXF9bM79xZvyRDQL66+Me2 0qrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=/dtoutPOEdCINHocW1rGR+2R83/wfd6HPoo9aE0vRoU=; b=a5ceTOCr5Qv8hnCiymXRuO9Z56EUB80YXkLD7jWA30+AWbXS6s0OIPM/jgLVmbIYVJ BwQukmpUSxGq+z+NAMD5ExovT7PpLKrEyzU45pYlxO+bhUHAtvIw4M2biEaiKiuwSiMc 3NMbnbXcUZ0TDd4A5HQ6HV+GAUkOJ/N41Ipi9yHSSFFhd075nLc3U70mN/bOLDRFybEN qIanpDU8LL7ktt1PqSgQ7B3MEGLgmZX9tFPyJttTdGUT9JmFiGmww8Ddx+OJXsA1vPmu Bivp2jyzcJEWHVT20QbJqhAF8BLNIo1nj41K44pSOAXIukJQsTKjvn8ofZsGYqMa23C+ S4/A== X-Gm-Message-State: AKS2vOz9OMf62fJ8NsR4MH4wlRukAoXjhRJS3GpBn8AP6BdIdVfMCXaN TyUUBipZV2xb9SNd X-Received: by 10.28.213.135 with SMTP id m129mr3688841wmg.78.1498205519504; Fri, 23 Jun 2017 01:11:59 -0700 (PDT) Received: from platinum (2a01cb0c03c651000226b0fffeed02fc.ipv6.abo.wanadoo.fr. [2a01:cb0c:3c6:5100:226:b0ff:feed:2fc]) by smtp.gmail.com with ESMTPSA id m73sm3528425wmi.25.2017.06.23.01.11.59 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 23 Jun 2017 01:11:59 -0700 (PDT) Date: Fri, 23 Jun 2017 10:11:57 +0200 From: Olivier Matz To: Jan Blunck Cc: dev , matvejchikov@gmail.com, Adrien Mazarguil , sergio.gonzalez.monroy@intel.com, stable@dpdk.org Message-ID: <20170623101157.43dcafe3@platinum> In-Reply-To: References: <20170609102727.0eb7f39d@platinum> <20170609082937.21294-1-olivier.matz@6wind.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] eal: don't advertise a physical address when no hugepages 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: Fri, 23 Jun 2017 08:12:00 -0000 Hi Jan, On Sat, 10 Jun 2017 10:31:22 +0200, Jan Blunck wrote: > On Fri, Jun 9, 2017 at 10:29 AM, Olivier Matz wrote: > > When populating a mempool with a virtual memory area, the mempool > > library expects to be able to get the physical address of each page. > > > > When started with --no-huge, the physical addresses may not be available > > because the pages are not locked in memory. It sometimes returns > > RTE_BAD_PHYS_ADDR, which makes the mempool_populate() function to fail. > > > > This was working before the commit cdc242f260e7 ("eal/linux: support > > running as unprivileged user"), because rte_mem_virt2phy() was returning > > 0 instead of RTE_BAD_PHYS_ADDR, which was seen as a valid physical > > address. > > > > Since --no-huge is a debug function that breaks the support of physical > > drivers, always set physical addresses to RTE_BAD_PHYS_ADDR in memzones > > or in rte_mem_virt2phy(), and ensure that mempool won't complain in that > > case. > > > > Fixes: cdc242f260e7 ("eal/linux: support running as unprivileged user") > > > > CC: stable@dpdk.org > > Signed-off-by: Olivier Matz > > --- > > lib/librte_eal/common/eal_common_memzone.c | 5 ++++- > > lib/librte_eal/linuxapp/eal/eal_memory.c | 7 +++++++ > > lib/librte_mempool/rte_mempool.c | 2 +- > > 3 files changed, 12 insertions(+), 2 deletions(-) > > > > diff --git a/lib/librte_eal/common/eal_common_memzone.c b/lib/librte_eal/common/eal_common_memzone.c > > index 3026e36b8..c465c8fc2 100644 > > --- a/lib/librte_eal/common/eal_common_memzone.c > > +++ b/lib/librte_eal/common/eal_common_memzone.c > > @@ -251,7 +251,10 @@ memzone_reserve_aligned_thread_unsafe(const char *name, size_t len, > > > > mcfg->memzone_cnt++; > > snprintf(mz->name, sizeof(mz->name), "%s", name); > > - mz->phys_addr = rte_malloc_virt2phy(mz_addr); > > + if (rte_eal_has_hugepages()) > > + mz->phys_addr = rte_malloc_virt2phy(mz_addr); > > + else > > + mz->phys_addr = RTE_BAD_PHYS_ADDR; > > Since you set phys_addrs_available to false rte_malloc_virt2phy() > anyway returns RTE_BAD_PHYS_ADDR so I believe the conditional isn't > necessary here. > > Rest of the patch looks good to me. The variable phys_addrs_available only impacts rte_mem_virt2phy(). Here, for memzones allocation, rte_malloc_virt2phy() is used, and it gets its physical address by retrieving it from the memseg structure. With the full patch, "dump_memzone" displays something like: Zone 0: name:, phys:0xffffffffffffffff, len:0x30100, [...] ... If I strip the memzone part, it displays: Zone 0: name:, phys:0x7fe382c62640, len:0x30100, [...] ... So I think we should either keep the patch as is, or change the memseg and malloc part like this (it's maybe better): --- a/lib/librte_eal/common/rte_malloc.c +++ b/lib/librte_eal/common/rte_malloc.c @@ -254,5 +254,7 @@ rte_malloc_virt2phy(const void *addr) const struct malloc_elem *elem = malloc_elem_from_data(addr); if (elem == NULL) return 0; + if (elem->ms->phys_addr == RTE_BAD_PHYS_ADDR) + return RTE_BAD_PHYS_ADDR; return elem->ms->phys_addr + ((uintptr_t)addr - (uintptr_t)elem->ms->addr); } diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c b/lib/librte_eal/linuxapp/eal/eal_memory.c index 1c99852..2a401ca 100644 --- a/lib/librte_eal/linuxapp/eal/eal_memory.c +++ b/lib/librte_eal/linuxapp/eal/eal_memory.c @@ -973,7 +973,7 @@ rte_eal_hugepage_init(void) strerror(errno)); return -1; } - mcfg->memseg[0].phys_addr = (phys_addr_t)(uintptr_t)addr; + mcfg->memseg[0].phys_addr = RTE_BAD_PHYS_ADDR; mcfg->memseg[0].addr = addr; mcfg->memseg[0].hugepage_sz = RTE_PGSIZE_4K; mcfg->memseg[0].len = internal_config.memory; Let me know what you are ok with this and I'll send a v2. Thanks, Olivier