From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 3A2126CD3 for ; Tue, 14 Jun 2016 15:21:41 +0200 (CEST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AC2E163E0E; Tue, 14 Jun 2016 13:21:40 +0000 (UTC) Received: from sopuli.koti.laiskiainen.org (vpn1-7-54.ams2.redhat.com [10.36.7.54]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5EDLd3l018185; Tue, 14 Jun 2016 09:21:39 -0400 To: Olivier Matz , sergio.gonzalez.monroy@intel.com, david.marchand@6wind.com, thomas.monjalon@6wind.com, dev@dpdk.org References: <1465813577-13780-1-git-send-email-olivier.matz@6wind.com> From: Panu Matilainen Message-ID: Date: Tue, 14 Jun 2016 16:21:38 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <1465813577-13780-1-git-send-email-olivier.matz@6wind.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 14 Jun 2016 13:21:40 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH] mem: skip memory locking on failure X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 13:21:41 -0000 On 06/13/2016 01:26 PM, Olivier Matz wrote: > Since recently [1], it is not possible to run the dpdk with user > (non-root) privileges and the --no-huge option. This is because the eal > layer tries to lock the memory. Using locked memory is mandatory for > physical devices because they reference physical addresses. > > But a user may want to start the dpdk without locked memory, because he > does not have the permission to do so, and/or does not have this need. > > Moreover, the option --no-huge is still not functional today since the > physical memory address is not properly filled, so the initial patch is > not really useful. > > This commit fixes this issue by retrying the mmap() wihout the > MAP_LOCKED flag if the first mmap() failed. > > [1] http://www.dpdk.org/ml/archives/dev/2016-May/039404.html > > Fixes: 593a084afc2b ("mem: lock pages when not using hugepages") > Reported-by: Panu Matilainen > Signed-off-by: Olivier Matz > --- > lib/librte_eal/linuxapp/eal/eal_memory.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c b/lib/librte_eal/linuxapp/eal/eal_memory.c > index 79d1d2d..08692d1 100644 > --- a/lib/librte_eal/linuxapp/eal/eal_memory.c > +++ b/lib/librte_eal/linuxapp/eal/eal_memory.c > @@ -1075,6 +1075,15 @@ rte_eal_hugepage_init(void) > if (internal_config.no_hugetlbfs) { > addr = mmap(NULL, internal_config.memory, PROT_READ | PROT_WRITE, > MAP_LOCKED | MAP_PRIVATE | MAP_ANONYMOUS, 0, 0); > + /* retry without MAP_LOCKED */ > + if (addr == MAP_FAILED && errno == EAGAIN) { > + addr = mmap(NULL, internal_config.memory, > + PROT_READ | PROT_WRITE, > + MAP_PRIVATE | MAP_ANONYMOUS, 0, 0); > + if (addr != MAP_FAILED) > + RTE_LOG(NOTICE, EAL, > + "Cannot lock memory: don't use physical devices\n"); > + } > if (addr == MAP_FAILED) { > RTE_LOG(ERR, EAL, "%s: mmap() failed: %s\n", __func__, > strerror(errno)); > I'm not really that familiar with dpdk memory usage, but gut feeling says such a thing needs to be explicit - either you explicitly ask for memory that doesn't need to be locked, or this simply fails with no retries. Or something like that. But "maybe I did, maybe I didn't" doesn't seem like very good API semantics to me :) Are there actual plans to make --no-huge work with real devices? If not then documenting --no-huge to imply unlocked memory is one option I guess. - Panu - - Panu -