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 D2268A04DB; Thu, 15 Oct 2020 13:15:21 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7150A1E497; Thu, 15 Oct 2020 13:15:20 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 564F61DD2A for ; Thu, 15 Oct 2020 13:15:18 +0200 (CEST) IronPort-SDR: bqq0hIB9q7MizZUHwYL9jXPs7aG9Gv4Q6fxOH+CIPRSEPpo52H794Tha9M+E+IwODhFI+MqKSl +CfaBV06vweQ== X-IronPort-AV: E=McAfee;i="6000,8403,9774"; a="153251341" X-IronPort-AV: E=Sophos;i="5.77,378,1596524400"; d="scan'208";a="153251341" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Oct 2020 04:15:17 -0700 IronPort-SDR: 5QpRgTw20uUB/EznnugBJCos862F9L3+zF6PVaaEvLHko4qH2bSZYRbyg0NpTHwD4azs3c+JQI zo1k9soY+Z0g== X-IronPort-AV: E=Sophos;i="5.77,378,1596524400"; d="scan'208";a="464258215" Received: from bricha3-mobl.ger.corp.intel.com ([10.213.245.94]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 15 Oct 2020 04:15:15 -0700 Date: Thu, 15 Oct 2020 12:15:11 +0100 From: Bruce Richardson To: Juraj =?utf-8?Q?Linke=C5=A1?= Cc: "dev@dpdk.org" Message-ID: <20201015111511.GA554@bricha3-MOBL.ger.corp.intel.com> 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 Thu, Oct 15, 2020 at 10:49:17AM +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. > Four seems a reasonable lower bound to have, but 32 seems high. I agree that the warning itself looks suspicious too. However, looking at the code and the line in question, I think there is indeed an app bug. The loop goes up to MAX_ETHPORTS, but the tx_bufs array being dereferenced is dimensioned by MAX_LCORES, which is why you hit problems with lcore values below 32 (==MAX_ETHPORTS). Based on the use, I suspect the structure definition may be wrong and the array should be dimensioned for MAX_ETHPORTS - but I haven't dug into the code further than that. Regards, /Bruce