From mboxrd@z Thu Jan 1 00:00:00 1970 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) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 2CABC3AC; Fri, 13 Jul 2018 08:15:47 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Fri, 13 Jul 2018 08:15:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=VMnTmEMuwOfkNlQdzm1lnNpM2/ Qezj8cNjvbyxxIkBc=; b=MSvk9CeVZYOxW1EwM3f/RN3+M80D0s8pNb5jXJzJUJ 7Gq1RWuvJmJPo9eliwaP9u5Oxz0+M5RY/rnPiI7g4ImvfNsdbNNMRQswkQBTDiyP 4yRwwyAHh2Stanzku1/fnN+H1Xtj9RzEEmRQniHZlXBhEYX1CVIDz1oLg0dmQ+oA A= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=VMnTmE MuwOfkNlQdzm1lnNpM2/Qezj8cNjvbyxxIkBc=; b=FQapLfs3cwO8izCN7HlbnL aq5SyIods7H3RycHnu1NplQ/u6E4Fn9Xg6LcUCTBcx7T4pC60ognrA9zj7wiDDzS yZCH5RO6Oa3Hoiuq7OnoJT6B0yF3+7CMT10H9Oecxj8hFZDJPdQ5K4zkArOm98l4 oYDqCcNCDWMWK8SeAoHOR2dZUcPEgC+J7YG47u3ov/njw/jkKPOfKmlfMjsn7Aqh IxuaLdoca1YbFI4aDPg4mvJQEdGQYVWyRg4T+bfdKdGpeez0PdPkE/IgsxlmcwTj y4P5RJboLzXB+cw1hIg1RMgtOUOBlFBXvFR4Lr6K3CPw4b/vIht5NMlrwq3KqyPw == X-ME-Proxy: X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 7DA5210277; Fri, 13 Jul 2018 08:15:45 -0400 (EDT) From: Thomas Monjalon To: Anatoly Burakov 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 Date: Fri, 13 Jul 2018 14:15:44 +0200 Message-ID: <2386265.Zj3uxajx9O@xps> In-Reply-To: <8fef5019ebdb9d941c1ade936fcdda1ace303738.1531477505.git.anatoly.burakov@intel.com> References: <8fef5019ebdb9d941c1ade936fcdda1ace303738.1531477505.git.anatoly.burakov@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v2 9/9] mem: support in-memory mode 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, 13 Jul 2018 12:15:48 -0000 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.