From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 2EB771DA4 for ; Tue, 24 Jul 2018 14:03:17 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 981A021193; Tue, 24 Jul 2018 08:03:16 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 24 Jul 2018 08:03:16 -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=RgQy7hgLbWgjORsGsQGpCktiby vumo0WqBrBOX3+z14=; b=ExNWnqaVU5aEYqZMIbPRsDoAW65uvyEGS95APT7E5c 9jVZTpvVjo8egRMUAH0337jhWgEvHF1DzufhHNGMf+x4Ua9rZKvdbSHu77eM1jM+ bgCu5IcoVMzKJB89sf3ykOKxXL+esQrYI4xzJjOWoKysl0s3fYlVXabofW1HZRKN E= 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=RgQy7h gLbWgjORsGsQGpCktibyvumo0WqBrBOX3+z14=; b=VazIUBibIGePWiTCJ2mATC SxAqg0Ji142AxI10p0mw5dCC6VbOBlqMWDzNkp8JHfZq3PBQ8ZUedtRs9tA8Syi0 Kl1Vrh8ymbGIKC3cg0xv6zMWGkLUPlOchMOrkxzEAJo4G+Chf2GvqH3eGXz4dr+r xH+lRqKvpaYnQrvQusBV2pIjQpLcdST3lyJ3taRLMlKzDuuFqPvidTh0xb8GXc/A jBrlwfIJF+QOWmI7Q6/2i+X3kPXnC53vKZjJJhfQZHTjYI5slbhfHxzwX2V5TB0X c8BdeVEL4iMoHhyLjrWsAsu+VQapR+OaVyu6YDZp8SfPEtOnzYd7mccg7+l3d9Zw == 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 693611026C; Tue, 24 Jul 2018 08:03:13 -0400 (EDT) From: Thomas Monjalon To: "Burakov, Anatoly" Cc: dev@dpdk.org, Ravi1.Kumar@amd.com, jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com, yskoh@mellanox.com, arybchenko@solarflare.com, damarion@cisco.com, ktraynor@redhat.com, stephen@networkplumber.org, olivier.matz@6wind.com, christian.ehrhardt@canonical.com, bluca@debian.org Date: Tue, 24 Jul 2018 14:03:08 +0200 Message-ID: <6155181.arAJIN2bNs@xps> In-Reply-To: References: <40cf48703f5fae8af8c31dcc8a1a1ecb0b151d27.1532426170.git.anatoly.burakov@intel.com> <7333019.QUcIvQh70r@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] config: reduce memory requirements for DPDK 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: Tue, 24 Jul 2018 12:03:17 -0000 24/07/2018 13:04, Burakov, Anatoly: > On 24-Jul-18 11:23 AM, Thomas Monjalon wrote: > > 24/07/2018 12:03, Anatoly Burakov: > >> It has been reported that current memory limitations do not work > >> well on an 8-socket machines in default configuration when big > >> page sizes are used [1]. > >> > >> Fix it by reducing memory amount reserved by DPDK by default to > >> 32G per page size per NUMA node. This translates to allowing us > >> to reserve 32G per page size per NUMA node on 8 nodes with 2 > >> page sizes. > >> > >> [1] https://mails.dpdk.org/archives/dev/2018-July/108071.html > >> > >> Signed-off-by: Anatoly Burakov > >> --- > >> > >> Notes: > >> We could have increased CONFIG_RTE_MAX_MEM_MB but this would've > >> brought other potential problems due to increased memory > >> preallocation, and secondary process initialization is flaky > >> enough as it is. I am willing to bet that 32G per page size is > >> more than enough for the majority of use cases, and any > >> application with bigger requirements could adjust config options > >> itself. > > [...] > >> -CONFIG_RTE_MAX_MEMSEG_PER_TYPE=32768 > >> -CONFIG_RTE_MAX_MEM_MB_PER_TYPE=131072 > >> +CONFIG_RTE_MAX_MEMSEG_PER_TYPE=16384 > >> +CONFIG_RTE_MAX_MEM_MB_PER_TYPE=32768 > > > > Ideally, it should be a run-time option. > > > > It can be, yes, and this can be worked on for next release. However, we > also need to have good default values that work across all supported > platforms. Yes sure, we can wait the next release for a run-time option. How can we be sure these default values are good enough? It would be good to have several acks from various projects or companies.