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 50BE54545F; Fri, 14 Jun 2024 19:50:33 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CB52B40B9A; Fri, 14 Jun 2024 19:50:32 +0200 (CEST) Received: from dkmailrelay1.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 18B5E40B95; Fri, 14 Jun 2024 19:50:32 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesys.local [192.168.4.10]) by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id E0D69208A1; Fri, 14 Jun 2024 19:50:31 +0200 (CEST) Content-class: urn:content-classes:message Subject: RE: [PATCH v2] app/testpmd: fix lcore ID restriction MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Jun 2024 19:50:29 +0200 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9F523@smartserver.smartshare.dk> In-Reply-To: <20240614082707.3a2becec@hermes.local> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-TNEF-Correlator: Thread-Topic: [PATCH v2] app/testpmd: fix lcore ID restriction Thread-Index: Adq+b1WHJR90Xy+STS6HL8Z94nfAyQAE1eQg References: <20240415194631.124343-1-sivaprasad.tummala@amd.com> <20240416095556.173787-1-sivaprasad.tummala@amd.com> <5de50671-73b8-432d-a1a2-ce6b3120e73d@amd.com> <5a0370e4-aa42-4bc4-a5a8-34c37b88b95f@amd.com> <20240613121330.71538e19@hermes.local> <3fad191a-1402-4bb2-9992-6e2f4a50d295@amd.com> <20240614082707.3a2becec@hermes.local> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Stephen Hemminger" , "Ferruh Yigit" Cc: "Sivaprasad Tummala" , , , , , 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 > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > Sent: Friday, 14 June 2024 17.27 >=20 > On Fri, 14 Jun 2024 10:01:02 +0100 > Ferruh Yigit wrote: >=20 > > On 6/13/2024 8:13 PM, Stephen Hemminger wrote: > > > On Thu, 13 Jun 2024 17:51:14 +0100 > > > Ferruh Yigit wrote: > > > > > >>> Hi Sivaprasad, > > >>> > > >>> Is this '(lcoreid_t)' cast required? Because of integer = promotion > I > > >>> think result will be correct without casting. > > >>> > > >>> (And without integer promotion considered, casting needs to be > done on > > >>> one of the variables, not to the result, because result may be > already > > >>> cast down I think. Anyway this is not required for this case = since > > >>> variables are u16.) > > >>> > > >> > > >> Why casing required (for record) is, > > >> 'nb_txq' -> uint16_t, promoted to 'int' > > >> 'nb_fwd_ports' -> uint16_t, promoted to 'int' > > >> (nb_txq * nb_fwd_ports) -> result 'int' > > >> nb_fwd_lcores -> 'uint32_t' > > >> > > >> comparison between 'int' & 'uint32_t' gives warning. After some > compiler > > >> version it is smart enough to not give a warning, but casting is > > >> required for old compilers. > > >> > > >> And back to my comment above, casting one of the parameter to > > >> 'lcoreid_t' also works, as it forcing promotion to 'unsigned int' > > >> instead. But logically casting looks odd, so keeping casting > result. > > > > > > Where is the integer promotion happening? > > > > > > > Raslan reported following compile error, this version of the patch = has > > the cast, but merged version, v3, doesn't. > > > > > > ``` > > ../../root/dpdk/app/test-pmd/config.c: In function > 'icmp_echo_config_setup': > > ../../root/dpdk/app/test-pmd/config.c:5159:30: error: comparison > between > > signed and unsigned integer expressions [-Werror=3Dsign-compare] > > if ((nb_txq * nb_fwd_ports) < nb_fwd_lcores) >=20 > That does look like a compiler bug. uint16 multiplied by uint16 should > be uint16. Not, C doesn't promote types like that. Arithmetic operations always = promote smaller types to int or unsigned int. And since uint16 fits in = int, uint16 is promoted to int (not unsigned int). > Not sure why DPDK keeps using small types like uint16 so much, doesn't > have any > real benefit since all this is in registers.