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 BF95145C98; Wed, 6 Nov 2024 17:06:52 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AB451402C3; Wed, 6 Nov 2024 17:06:52 +0100 (CET) Received: from fout-b6-smtp.messagingengine.com (fout-b6-smtp.messagingengine.com [202.12.124.149]) by mails.dpdk.org (Postfix) with ESMTP id 93959402B2 for ; Wed, 6 Nov 2024 17:06:51 +0100 (CET) Received: from phl-compute-07.internal (phl-compute-07.phl.internal [10.202.2.47]) by mailfout.stl.internal (Postfix) with ESMTP id 80B32114011D; Wed, 6 Nov 2024 11:06:50 -0500 (EST) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-07.internal (MEProxy); Wed, 06 Nov 2024 11:06:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1730909210; x=1730995610; bh=ylgT2d+gyc4HpufQj4Q/ACBM0+GrGaKLX/41OwLhmbc=; b= hGWvvdzRw9WV0HD4u+DXZqDWMyngX4a/jBq2HCVYZlOklVolztubH68X1ftgatwf A4/EI8Jei1Rysn6xhiinyIvRT4keflPFZmqTd5LY0+Bjwns3ELhIzM/fLkBiG2H4 8QYZgcZ09UN+IgdyciP6f0rm7wJuezxM/y3cmF2SgKX0Hn2BcSePBqsr4pK+OjEN glMMmwjHrjG0G5RXaEGMCRPacJZrGStzJDU3poIP61MeG1iBmbHZVaYiEfptNAgB yskQ480tdFLerCprfGmZ918nU70geB1e3Br7eQ1+To3u1dNBsiXr0tAQ5KfumX8V oXco7lcOek2wYxHpzqR6Kg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1730909210; x= 1730995610; bh=ylgT2d+gyc4HpufQj4Q/ACBM0+GrGaKLX/41OwLhmbc=; b=B ynegiXqhgNf82bXswpW5UtiM5eiSi/UsCL4pcf51Fr23/ddqlCkW2hhvVee0sHoZ uz1GwPqgEwY8nPiBgrre9R6LMvNb4L/S9RAMIxKyrun0D5iRqw0x7ac2E76K/qoS aK2itID+ezGckjMEel2JOJjF+Xl8pDvY3Cmeebcefb8SJPexHu0sHrNVYfxNolYU LYVx+2ntpdWdLu4gUuJmzTQKaCsfjfUuicnUzrVzA2nNvvEq+u8K9TaTLopvn6k/ 5heUUmBtgBy2uu1zicxW/SeyMWnVbyQJ/1+MWiDn1IiLe21ROKX5F8RSwJNxTFqL iJ2n5LWuEHt7LB0F3N1yg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrtddvgdekfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth hsucdlqddutddtmdenucfjughrpefhvfevufffkfgjfhgggfgtsehtqhertddttdejnecu hfhrohhmpefvhhhomhgrshcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlh honhdrnhgvtheqnecuggftrfgrthhtvghrnhepgedttdeljeejgeffkeekkedtjeevtdeh vedtkeeivdeuuedvieduvdelveejueejnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvthdpnhgs pghrtghpthhtohepuddvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegsrhhutg gvrdhrihgthhgrrhgushhonhesihhnthgvlhdrtghomhdprhgtphhtthhopehmsgesshhm rghrthhshhgrrhgvshihshhtvghmshdrtghomhdprhgtphhtthhopeguvghvseguphgukh drohhrghdprhgtphhtthhopehrohhrvghtiihlrgeslhhinhhugidrmhhitghrohhsohhf thdrtghomhdprhgtphhtthhopehfvghrrhhuhhdrhihighhithesrghmugdrtghomhdprh gtphhtthhopegrnhgurhgvfidrrhihsggthhgvnhhkohesohhkthgvthhlrggsshdrrhhu pdhrtghpthhtoheprghjihhtrdhkhhgrphgrrhguvgessghrohgruggtohhmrdgtohhmpd hrtghpthhtohepshhomhhnrghthhdrkhhothhurhessghrohgruggtohhmrdgtohhmpdhr tghpthhtohepghhrihhvvgesuhdvheeirdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 6 Nov 2024 11:06:47 -0500 (EST) From: Thomas Monjalon To: Bruce Richardson , Morten =?UTF-8?B?QnLDuHJ1cA==?= Cc: dev@dpdk.org, Tyler Retzlaff , Ferruh Yigit , Andrew Rybchenko , Ajit Khaparde , Somnath Kotur , Gaetan Rivet , Jie Hai , Long Li , Wei Hu Subject: Re: [PATCH 2/2] drivers/net: support single queue per port Date: Wed, 06 Nov 2024 17:06:45 +0100 Message-ID: <5956521.peFUeoqG7q@thomas> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F88A@smartserver.smartshare.dk> References: <20241025115223.1230680-1-mb@smartsharesystems.com> <98CBD80474FA8B44BF855DF32C47DC35E9F88A@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 06/11/2024 13:19, Morten Br=C3=B8rup: > > From: Bruce Richardson [mailto:bruce.richardson@intel.com] > > Sent: Wednesday, 6 November 2024 12.52 > >=20 > > On Fri, Oct 25, 2024 at 11:52:23AM +0000, Morten Br=C3=B8rup wrote: > > > When configuring DPDK for one queue per port > > > (#define RTE_MAX_QUEUES_PER_PORT 1), compilation of some network > > drivers > > > fails with e.g.: > > > > > > ../drivers/net/bnxt/bnxt_rxq.c: In function 'bnxt_rx_queue_stop': > > > ../drivers/net/bnxt/bnxt_rxq.c:587:34: error: array subscript 1 is > > above array bounds of 'uint8_t[1]' {aka 'unsigned char[1]'} [- > > Werror=3Darray-bounds=3D] > > > 587 | dev->data->rx_queue_state[q_id] =3D > > RTE_ETH_QUEUE_STATE_STOPPED; > > > | ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~ > > > In file included from ../drivers/net/bnxt/bnxt.h:16, > > > from ../drivers/net/bnxt/bnxt_rxq.c:10: > > > ../lib/ethdev/ethdev_driver.h:168:17: note: while referencing > > 'rx_queue_state' > > > 168 | uint8_t rx_queue_state[RTE_MAX_QUEUES_PER_PORT]; > > > | ^~~~~~~~~~~~~~ > > > > > > To fix this, a hint is added to the network drivers where a compiler > > in > > > the CI has been seen to emit the above error when DPDK is configured > > for > > > one queue per port, but we know that the error cannot occur. [...] > > > for (i =3D 0; i < dev->data->nb_rx_queues; i++) { > > > + __rte_assume(i < RTE_MAX_QUEUES_PER_PORT); > > > rxq =3D dev->data->rx_queues[i]; [...] > > BTW: is this the only/best way to put in the assumption? If it were me, > > I'd > > look to put before the loop the underlying assumption that > > (dev->data->nb_XX_queues < RTE_MAX_QUEUES_PER_PORT), rather than > > putting > > the assumption on "i". >=20 > I would also prefer putting it outside the loop, > but it doesn't work in cases where the variable > is potentially modified inside the loop. > And here's the problem with that: > Passing it as a parameter to a logging macro > makes the compiler think it is "potentially modified". I don't understand this part. "i" is not a pointer, so how it can be modified? > And thus, I have to put it where it hurts, and decided to do it consisten= tly. Why doing something heavier consistently? I would prefer to catch the problematic cases only with this macro.