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 C9F344545E for ; Fri, 14 Jun 2024 17:27:12 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C3BA64278C; Fri, 14 Jun 2024 17:27:12 +0200 (CEST) Received: from mail-pj1-f52.google.com (mail-pj1-f52.google.com [209.85.216.52]) by mails.dpdk.org (Postfix) with ESMTP id 4A9B1402D0 for ; Fri, 14 Jun 2024 17:27:11 +0200 (CEST) Received: by mail-pj1-f52.google.com with SMTP id 98e67ed59e1d1-2bfdae7997aso1943080a91.2 for ; Fri, 14 Jun 2024 08:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1718378830; x=1718983630; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=YU1j1smPzVWjuBPdqtZkTtPtKnG/hG+pZuDHgSeBOBs=; b=et05+CLJ70Vw0cs3AlUOwq254l21pB6ixn426mqJF4MkAgBMX+SXg8n30PNKnt5bP0 yZaT/WemLEJz+ZNwBBlzInL866XXCRn7o7F+trO2WPrC10m41xte1f1JgS+SHg8SSg6/ hymdIA6TojN0Gcfg0hkYus1pM5EpniiUL0YaLWqUv4W3mzCovlQhSew3l4MRNZoC7H2T TDlqBDJcpkCe7MIcNI7tCOcS39aOndGgYwd1g2RgMct9jWSvWlJ3/zL0tg3zSp1nrNaf 9j3TcvofB/ESpA6p3nyrPkiqasK28WMu8+FiT7yp16utcisfwLSdXTV5YWbGKwACNkkg x00Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718378830; x=1718983630; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=YU1j1smPzVWjuBPdqtZkTtPtKnG/hG+pZuDHgSeBOBs=; b=OITZ+xet1OWdurdVwKB0wtLePGxr81FQuaEtYEskk++VN805fZjDQsmau2MNhDQRr1 SYh2ipj8p6aImeM/JI+3mJ5BwWuRPVvlply6nvmTr27xZo4gL0xspgz+3I4EC4BrIZFI 5IkWIadCbG+mioFvvljmn0y6LoUw/U+63yVl0AAcHSAthdO6Ux7O2F82iU4WU/NEs2YN pGLaLPxOdu87V49ScppHBOtq/e3DYecSZORbvwU8odZIEFSwQA/Zp2cgx5tDmA56oLiQ hTlEN9nbvakdc5Z5W55Vny5AeXC+PfrZVK3iSJjEyHZQJn+Pw2Xl5uvkSsdCfgD8FAg4 G9bQ== X-Forwarded-Encrypted: i=1; AJvYcCVJTkjvLzlakdP8bXPzj5Hg4RxK8FVMUxqVoHNuRwAPC7OzzkM2f/Ak7FVmTSi5QtfqqsX1rN0iQmCRcLHLaN8= X-Gm-Message-State: AOJu0Yx0lFjobRwlecNWQpfKIHPKZ1aJjBLdK2Axoj2D3CSt+KlGN1iC bsWkRT4f8tjM9GFsH0sm3g29F9AWV33SZMwu0nd0lHHchObxRtgzMwsZB77OjHw= X-Google-Smtp-Source: AGHT+IEp2DwOf7yVd/giqO7G7OFGhTXrnfnRUbA9M5/YUXRq9/a7MPFXxX7vs4DXB8yGjNJ0abLqUg== X-Received: by 2002:a17:90a:bc83:b0:2c4:b515:46d4 with SMTP id 98e67ed59e1d1-2c4db135067mr3160595a91.3.1718378830276; Fri, 14 Jun 2024 08:27:10 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2c4c45fa925sm4029275a91.29.2024.06.14.08.27.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Jun 2024 08:27:09 -0700 (PDT) Date: Fri, 14 Jun 2024 08:27:07 -0700 From: Stephen Hemminger To: Ferruh Yigit Cc: Sivaprasad Tummala , david.marchand@redhat.com, aman.deep.singh@intel.com, yuying.zhang@intel.com, dev@dpdk.org, stable@dpdk.org Subject: Re: [PATCH v2] app/testpmd: fix lcore ID restriction Message-ID: <20240614082707.3a2becec@hermes.local> In-Reply-To: <3fad191a-1402-4bb2-9992-6e2f4a50d295@amd.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org On Fri, 14 Jun 2024 10:01:02 +0100 Ferruh Yigit wrote: > 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=sign-compare] > if ((nb_txq * nb_fwd_ports) < nb_fwd_lcores) That does look like a compiler bug. uint16 multiplied by uint16 should be uint16. Not sure why DPDK keeps using small types like uint16 so much, doesn't have any real benefit since all this is in registers. ^