From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2006DA0C4C; Thu, 14 Oct 2021 10:25:24 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A08574112E; Thu, 14 Oct 2021 10:25:23 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by mails.dpdk.org (Postfix) with ESMTP id 7845C40041 for ; Thu, 14 Oct 2021 10:25:22 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10136"; a="214570091" X-IronPort-AV: E=Sophos;i="5.85,372,1624345200"; d="scan'208";a="214570091" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Oct 2021 01:25:21 -0700 X-IronPort-AV: E=Sophos;i="5.85,372,1624345200"; d="scan'208";a="442017377" Received: from bdcaprar-mobl1.ger.corp.intel.com (HELO bricha3-MOBL.ger.corp.intel.com) ([10.252.25.39]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 14 Oct 2021 01:25:20 -0700 Date: Thu, 14 Oct 2021 09:25:17 +0100 From: Bruce Richardson To: Kefu Chai Cc: dev@dpdk.org, Thomas Monjalon , Avi Kivity , anatoly.burakov@intel.com Message-ID: References: <20210902144805.105098-1-tchaikov@gmail.com> <20211013205417.84119-3-tchaikov@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211013205417.84119-3-tchaikov@gmail.com> Subject: Re: [dpdk-dev] [PATCH v5 2/2] build: add meson options of max_memseg_lists X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, Oct 14, 2021 at 04:54:19AM +0800, Kefu Chai wrote: > RTE_MAX_MEMSEG_LISTS = 128 is not enough for many-core machines, in our > case, we need to increase it to 8192. so add an option so user can > override it. > > Signed-off-by: Kefu Chai This seems a very low-level option to be exposing to the user. Some thoughts/questions: - can you give some more detail on why you need such a massive number, 64 times the default? - what would be the impact of increasing the default to 8192? I assume this is only used in a few places in EAL, so would the memory footprint increase be large? - rather than a single specified value, would an alternative be to make this be a computed value at config time, scaled by number of lcores (or number of numa nodes)? Regards, /Bruce