From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 1DFE6A04DB; Thu, 15 Oct 2020 13:30:59 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id EE9881DC0E; Thu, 15 Oct 2020 13:30:57 +0200 (CEST) Received: from relay11.mail.gandi.net (relay11.mail.gandi.net [217.70.178.231]) by dpdk.org (Postfix) with ESMTP id 6A17B1DBBE for ; Thu, 15 Oct 2020 13:30:56 +0200 (CEST) Received: from u256.net (lfbn-poi-1-843-59.w86-254.abo.wanadoo.fr [86.254.165.59]) (Authenticated sender: grive@u256.net) by relay11.mail.gandi.net (Postfix) with ESMTPSA id 12D45100003; Thu, 15 Oct 2020 11:30:54 +0000 (UTC) Date: Thu, 15 Oct 2020 13:30:50 +0200 From: =?utf-8?Q?Ga=C3=ABtan?= Rivet To: Juraj =?utf-8?Q?Linke=C5=A1?= Cc: "dev@dpdk.org" Message-ID: <20201015113050.etp277lf4q6qrtko@u256.net> References: <317a9b0f7130448190e2391150bd0f67@pantheon.tech> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <317a9b0f7130448190e2391150bd0f67@pantheon.tech> Subject: Re: [dpdk-dev] Minimun value of RTE_MAX_LCORE 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 15/10/20 10:49 +0000, Juraj Linkeš wrote: > Hi dpdk devs, > > Is there a constraint on how low RTE_MAX_LCORE can be? I'm implementing a discovery mechanism that sets RTE_MAX_LCORE according to the number of host cores, but I'm hitting errors when the values are low: > https://travis-ci.com/github/jlinkes/dpdk/jobs/399596828 > Message: Found 2 > cores > Message: Found 1 > numa nodes > > ../app/test/test_rcu_qsbr.c:296:54: error: iteration 2 invokes undefined behavior [-Werror=aggressive-loop-optimizations] > > ../app/test/test_rcu_qsbr.c:315:55: error: array subscript is above array bounds [-Werror=array-bounds] > > All VM jobs failed in that Travis build. Travis VMs only have 2 cores, so I tried to put a bound on the build. I set it to 4 and all jobs except GCC shared lib jobs passed, which still threw iteration 4 invokes undefined behavior error: > https://travis-ci.com/github/jlinkes/dpdk/jobs/400004089 > > ../examples/performance-thread/l3fwd-thread/main.c:2338:34: error: iteration 4 invokes undefined behavior [-Werror=aggressive-loop-optimizations] > > This happens for number of cores < 32 and looks like a limitation unique to l3fwd (with cores between 4 and 32 - I didn't see the error elsewhere). > > Should I use the bound or are these legitimate errors? The fact that only GCC (and not clang) shared lib jobs failed is also suspicious. > > Thanks, > Juraj > Hi, I can see a CPU config setting it to 4, so it might be a valid value. Not sure it would be the lower bound though. However, I think the issue you get here shows why your discovery mechanism is not great. Most of the time, DPDK applications are not built on their target machine: either due to CI (like your issue), automatic packaging, cross-compilation for smartNIC, etc. Platforms that would benefit from your discovery mechanism will define RTE_MAX_LCORE explicitly, e.g. in config/arm/meson.build, line 34 and further. Regards, -- Gaëtan