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 0C885ADB9 for ; Fri, 20 May 2016 10:42:50 +0200 (CEST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (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 561406406A; Fri, 20 May 2016 08:42:49 +0000 (UTC) Received: from sopuli.koti.laiskiainen.org (vpn1-6-156.ams2.redhat.com [10.36.6.156]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u4K8glgS013405; Fri, 20 May 2016 04:42:47 -0400 To: Thomas Monjalon , Olivier Matz References: <1460629199-32489-1-git-send-email-olivier.matz@6wind.com> <1463569496-31086-1-git-send-email-olivier.matz@6wind.com> <36612895.rbhkJEDisP@xps13> Cc: dev@dpdk.org, bruce.richardson@intel.com, stephen@networkplumber.org, keith.wiles@intel.com From: Panu Matilainen Message-ID: <9d61a426-f580-b39e-1e38-7a30a4937324@redhat.com> Date: Fri, 20 May 2016 11:42:47 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <36612895.rbhkJEDisP@xps13> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 20 May 2016 08:42:49 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH v3 00/35] mempool: rework memory allocation 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: Fri, 20 May 2016 08:42:50 -0000 On 05/19/2016 03:47 PM, Thomas Monjalon wrote: > 2016-05-18 13:04, Olivier Matz: >> This series is a rework of mempool. For those who don't want to read >> all the cover letter, here is a sumary: >> >> - it is not possible to allocate large mempools if there is not enough >> contiguous memory, this series solves this issue >> - introduce new APIs with less arguments: "create, populate, obj_init" >> - allow to free a mempool >> - split code in smaller functions, will ease the introduction of ext_handler >> - remove test-pmd anonymous mempool creation >> - remove most of dom0-specific mempool code >> - opens the door for a eal_memory rework: we probably don't need large >> contiguous memory area anymore, working with pages would work. >> >> This breaks the ABI as it was indicated in the deprecation for 16.04. >> The API stays almost the same, no modification is needed in examples app >> or in test-pmd. Only kni and mellanox drivers are slightly modified. > > Applied with a small change you sent me to fix mlx build in the middle of the patchset > and update the removed Xen files in MAINTAINERS file. > > Thanks for the big rework! > Just noticed this series "breaks" --no-huge as a regular user, commit 593a084afc2b to be exact: mmap(NULL, 4194304, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_LOCKED, 0, 0) = -1 EAGAIN (Resource temporarily unavailable) write(1, "EAL: rte_eal_hugepage_init: mmap"..., 76EAL: rte_eal_hugepage_init: mmap() failed: Resource temporarily unavailable "Breaks" in quotes because I guess it always was broken (as the non-locked pages might not be in physical memory) and because its possible to adjust resourse limits to allow the operation to succeed. If you're root, that is. I was just looking into making the test-suite runnable by a regular user with no special privileges, primarily to make it possible to run the testsuite as part of rpm package builds (in %check), and no special setup or extra privileges can be assumed there. Such tests are of course of limited coverage but still better than nothing, and --no-huge was my ticket there. Talk about bad timing :) It'd be fine to have limited subset of tests to run when non-privileged but since this one lives inside rte_eal_init() it practically prevents everything, unless I'm missing some other magic switch or such. Thoughts? - Panu -