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 7A29DA0C41; Thu, 18 Nov 2021 14:52:35 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EDF1F40687; Thu, 18 Nov 2021 14:52:34 +0100 (CET) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by mails.dpdk.org (Postfix) with ESMTP id 21F3540395; Thu, 18 Nov 2021 14:52:32 +0100 (CET) X-IronPort-AV: E=McAfee;i="6200,9189,10171"; a="294999352" X-IronPort-AV: E=Sophos;i="5.87,245,1631602800"; d="scan'208";a="294999352" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Nov 2021 05:52:32 -0800 X-IronPort-AV: E=Sophos;i="5.87,245,1631602800"; d="scan'208";a="455331892" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.21.106]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 18 Nov 2021 05:52:30 -0800 Date: Thu, 18 Nov 2021 13:52:26 +0000 From: Bruce Richardson To: Thomas Monjalon Cc: Aman Kumar , David Marchand , "Song, Keesang" , techboard@dpdk.org, dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] config/x86: add support for AMD platform Message-ID: References: <20211102145253.413467-1-aman.kumar@vvdntech.in> <1902057.C4l9sbjloW@thomas> <4391381.llMs6SCV4p@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4391381.llMs6SCV4p@thomas> 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 On Thu, Nov 18, 2021 at 01:25:38PM +0100, Thomas Monjalon wrote: > I request a techboard decision for this patch. > > > 02/11/2021 20:04, Thomas Monjalon: > > 02/11/2021 19:45, David Marchand: > > > On Tue, Nov 2, 2021 at 3:53 PM Aman Kumar wrote: > > > > > > > > -Dcpu_instruction_set=znverX meson option can be used > > > > to build dpdk for AMD platforms. Supported options are > > > > znver1, znver2 and znver3. > > > > > > > > Signed-off-by: Aman Kumar > > > > --- > > > > dpdk_conf.set('RTE_CACHE_LINE_SIZE', 64) > > > > dpdk_conf.set('RTE_MAX_LCORE', 128) > > > > dpdk_conf.set('RTE_MAX_NUMA_NODES', 32) > > > > + > > > > +# AMD platform support > > > > +if get_option('cpu_instruction_set') == 'znver1' > > > > + dpdk_conf.set('RTE_MAX_LCORE', 256) > > > > +elif get_option('cpu_instruction_set') == 'znver2' > > > > + dpdk_conf.set('RTE_MAX_LCORE', 512) > > > > +elif get_option('cpu_instruction_set') == 'znver3' > > > > + dpdk_conf.set('RTE_MAX_LCORE', 512) > > > > +endif > > > > > > I already replied to a similar patch earlier in this release. > > > https://inbox.dpdk.org/dev/CAJFAV8z-5amvEnr3mazkTqH-7SZX_C6EqCua6UdMXXHgrcmT6g@mail.gmail.com/ > > > > > > So repeating the same: do you actually _need_ more than 128 lcores in > > > a single DPDK application? > > We did not receive an answer to this question. > > > Yes I forgot this previous discussion concluding that we should not increase > > more than 128 threads. > > We had a discussion yesterday in techboard meeting. > The consensus is that we didn't hear for real need of more than 128 threads, > except for configuration usability convenience. > > Now looking again at the code, this is how it is defined: > > option('max_lcores', type: 'string', value: 'default', description: > 'Set maximum number of cores/threads supported by EAL; > "default" is different per-arch, "detect" detects the number of cores on the build machine.') > config/x86/meson.build: dpdk_conf.set('RTE_MAX_LCORE', 128) > config/ppc/meson.build: dpdk_conf.set('RTE_MAX_LCORE', 128) > config/arm/meson.build: it goes from 4 to 1280! > > So I feel it is not fair to reject this AMD patch if we allow Arm to go beyond. > Techboard, let's have a quick decision please for 21.11-rc4. > I would support increasing the default value for x86 in this release. I believe Dave H. had some patches to decrease the memory footprint overhead of such a change. I don't believe that they were merged, and while it's a bit late for 21.11 now, those should be considered for 22.03 release and then maybe for backport. /Bruce