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 DEB4BA034F; Fri, 10 Sep 2021 09:54:48 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6931F40041; Fri, 10 Sep 2021 09:54:48 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by mails.dpdk.org (Postfix) with ESMTP id 4B7D74003E for ; Fri, 10 Sep 2021 09:54:47 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10102"; a="282037327" X-IronPort-AV: E=Sophos;i="5.85,282,1624345200"; d="scan'208";a="282037327" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Sep 2021 00:54:46 -0700 X-IronPort-AV: E=Sophos;i="5.85,282,1624345200"; d="scan'208";a="504964030" Received: from lcostigx-mobl2.ger.corp.intel.com (HELO bricha3-MOBL.ger.corp.intel.com) ([10.252.4.132]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 10 Sep 2021 00:54:44 -0700 Date: Fri, 10 Sep 2021 08:54:39 +0100 From: Bruce Richardson To: David Marchand Cc: David Hunt , dev Message-ID: References: <20210909134511.18871-1-david.hunt@intel.com> <20210909134511.18871-2-david.hunt@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [PATCH v1 1/6] build: increase default of max lcores to 512 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 Fri, Sep 10, 2021 at 08:51:04AM +0200, David Marchand wrote: > On Thu, Sep 9, 2021 at 4:38 PM Bruce Richardson > wrote: > > > > On Thu, Sep 09, 2021 at 02:45:06PM +0100, David Hunt wrote: > > > Modern processors are coming with an ever increasing number of cores, > > > and 128 does not seem like a sensible max limit any more, especially > > > when you consider multi-socket systems with Hyper-Threading enabled. > > > > > > This patch increases max_lcores default from 128 to 512. > > > > > > Signed-off-by: David Hunt > > Why should we need this? > > --lcores makes it possible to pin 128 lcores to any physical core on > your system. > And for applications that have their own thread management, they can > pin thread, then use rte_thread_register. > > Do you have applications that require more than 128 lcores? > The trouble is that using the --lcores syntax for mapping high core numbers to low lcore ids is much more awkward to use. Every case of DPDK use I've seen uses -c with a coremask, or -l with just giving a few core numbers on it. This simple scheme won't work with core numbers greater than 128, and there are already systems available with more than that number of cores. Apart from the memory footprint issues - which this patch is already making a good start in addressing, why would we not increase the default max_lcores to that seen on real systems? /Bruce