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 732A8A0547; Fri, 10 Sep 2021 10:25:03 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5E71F40041; Fri, 10 Sep 2021 10:25:03 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by mails.dpdk.org (Postfix) with ESMTP id 4AD334003E for ; Fri, 10 Sep 2021 10:25:02 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id B12AC5C0145; Fri, 10 Sep 2021 04:25:01 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Fri, 10 Sep 2021 04:25:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= vqH6WJ/ObwCag/qckszS1x+N6QgTSqauqiUJsyh2Oi0=; b=Hx6fSQeIh/0Txjef KL48x2bTNlzKBNUU0hsb1gs8sF705trA7jwqUvtw9Bkj1xbkPDlanY/xKEoS6LwS JR+yCobezscHAS20QJZTSR10KkLQ7VppJAO5oDXk4vjFbSak4xAJjLQJTCleAhjL /N6/CjmLsNN557giR2UiYHOIcmBFoTFlgzEwWeFfVzdJr59BKWPeqI/Zu/4fKg9P ELkc+HxQLKReKnBxJi/kiAYAoiCeGlCfaUqL6D0qqGDuxomBJwltqNp2CrK9lvS5 vKYNaldJIkXpc6HIXKaBiLZeOWcOq22CcAhdRQcL18aBDz0r7wevYdCLe6nyThpf ujiHyw== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=vqH6WJ/ObwCag/qckszS1x+N6QgTSqauqiUJsyh2O i0=; b=ZNKFyvFFKhJFcpIfFRz1b/l0H1CTfFat7lIKO9wL+tSSxGaGhd+PRai6g C6c6jPtrAYpSGPgptXgX0gE8FP0ixgjnQw3TMc5HIsxXxyDTlniN9TQv2rhVm6HS ErhkK0QTujPN1hhPKcQkdPAhN3wwvuncZiL4DcIasf0tDhR4Zf5GEW+5JGAsM7Na EujIyfkREkHGbxmK9HBwBwH3ZEFLJaQkztXNt/0xoET98OE49AWHt1DilhBIZt8t 2nAytJ2VjeGZWTcOj/iRRYpxxfdN25r0Kbiy8az/q6HGCjES6RgWzp7oFrfBTAsW cY2YohgaPxeq4GI1te0s7V9OQzfpA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudeguddgtddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 10 Sep 2021 04:25:00 -0400 (EDT) From: Thomas Monjalon To: Bruce Richardson , David Hunt , David Marchand Cc: dev@dpdk.org Date: Fri, 10 Sep 2021 10:24:59 +0200 Message-ID: <5148108.61zlV0aQVf@thomas> In-Reply-To: References: <20210909134511.18871-1-david.hunt@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 10/09/2021 10:06, David Marchand: > On Fri, Sep 10, 2021 at 9:54 AM Bruce Richardson > wrote: > > > > 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? > > The memory footprint is a major issue to me, and reserving all those > lcores won't be needed in any system. > We will also have to decide on a "640k ought to be enough" value to > avoid ABI issue with the next processor that comes out and has more > than 512 cores. > > Could we wire the -c / -l options to --lcores behavior ? > It breaks the 1:1 lcore/physical core assumption, but it solves your > usability issue. Why would we change existing options while we already have an option (--lcores) which solves the issue above? I think the only issue is to educate users. Is there something to improve in the documentation?