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 CB71F4545E; Fri, 14 Jun 2024 17:27:11 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A25D140B95; Fri, 14 Jun 2024 17:27:11 +0200 (CEST) Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.41]) by mails.dpdk.org (Postfix) with ESMTP id 4D4F440B95 for ; Fri, 14 Jun 2024 17:27:11 +0200 (CEST) Received: by mail-pj1-f41.google.com with SMTP id 98e67ed59e1d1-2bfffa3c748so1941267a91.3 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=B7c2/6sDT3X3ujAQvjhlAHyQWbyF4Pr52T0U3tYYqhHxC3uCDa8AsjO6tNlMIqZ7ww GgbSLgZYFQV27CSb5IZ78CDrSrkdxJwHMdPX/vx37kfqstKoPuP6TKTrLNmF6cnmLQLZ 7ZAi3eUe87Mn6ewsEM5WR7vdPf3vF/aruhc/iJ0rFC1fa9zlS6LEVMWRgtL0ledPVxyS Js5oDeFRvz67ToG/n2pVZoRRqgSLG825R7NV1T8SavVtZFlEPFV8VGlMKNnvp/6ttUDY NUcungSTA6FUE0WpJ7eFQo2rixqtXa+zxpSg+3r/fCuz2nGOwJbhP5WA0p8PJL1mHGWB mL2w== X-Forwarded-Encrypted: i=1; AJvYcCViH297M4EdFLaqnzHriEQnJz31S1SYiS9t1YjMNb6/yLANGA75VTAOP2JvQRlwnysHpuTvytSDYDATQqM= X-Gm-Message-State: AOJu0YzhXdJRl0GDyfL/p7YsjBGpiFNAZJDTfFnj0q6/3b6ZazJDUiqW KjHok1e880jIvAWVXMOETLGhQLjoZMW1FO9p0LrSIWZDc2W9ACaxyqh95A13zds= 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: 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 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. ^