From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v2 9/9] mem: support in-memory mode Date: Fri, 13 Jul 2018 14:15:44 +0200 Message-ID: <2386265.Zj3uxajx9O@xps> References: <8fef5019ebdb9d941c1ade936fcdda1ace303738.1531477505.git.anatoly.burakov@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Cc: dev@dpdk.org, ray.kinsella@intel.com, kuralamudhan.ramakrishnan@intel.com, louise.m.daly@intel.com, bruce.richardson@intel.com, ferruh.yigit@intel.com, konstantin.ananyev@intel.com To: Anatoly Burakov Return-path: Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by dpdk.org (Postfix) with ESMTP id 6C8DA14EC for ; Fri, 13 Jul 2018 14:15:48 +0200 (CEST) In-Reply-To: <8fef5019ebdb9d941c1ade936fcdda1ace303738.1531477505.git.anatoly.burakov@intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" There is a compilation error: =2E./lib/librte_eal/linuxapp/eal/eal_memalloc.c: In function =E2=80=98alloc= _seg=E2=80=99: =2E./lib/librte_eal/linuxapp/eal/eal_memalloc.c:619:3: error: =E2=80=98map_offset=E2=80=99 may be used uninitialized in this function 13/07/2018 12:27, Anatoly Burakov: > Implement the final piece of the in-memory mode puzzle - enable running > DPDK entirely in memory, without creating any files. >=20 > To do it, use mmap with MAP_HUGETLB and size flags to enable DPDK to work > without hugetlbfs mountpoints. In order to enable this, a few things need= ed > to be changed. >=20 > First of all, we need to allow empty hugetlbfs mountpoints in > hugepage_info, and handle them correctly (by not trying to create any > files and lock any directories). >=20 > Next, we need to reorder the mapping sequence, because the page is not > really allocated until the page fault, and we cannot get its IOVA > address before we trigger the page fault. >=20 > Finally, decide at compile time whether we are going to be supporting > anonymous hugepages or not, because we cannot check for it at runtime. >=20 > Signed-off-by: Anatoly Burakov > --- >=20 > Notes: > RFC->v1: > - Drop memfd and instead use mmap() with MAP_HUGETLB. This will drop = the > kernel requirements down to 3.8, and does not impose any restrictio= ns > glibc (as far as i known). > =20 > Unfortunately, there's a bit of an issue with this approach, because > mmap() is stupid and will happily ignore unsupported arguments. This > means that if the binary were to be compiled on a 3.8+ kernel but r= un > on a pre-3.8 kernel (such as currently supported minimum of 3.2), t= hen > most likely the memory would be allocated using regular pages, caus= ing > unthinkable performance degradation. No solution to this problem is > currently known to me.