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 457DE45420 for ; Thu, 13 Jun 2024 21:13:36 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3CCF541153; Thu, 13 Jun 2024 21:13:36 +0200 (CEST) Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) by mails.dpdk.org (Postfix) with ESMTP id BC14B402E4 for ; Thu, 13 Jun 2024 21:13:33 +0200 (CEST) Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-1f8507aac31so12718085ad.3 for ; Thu, 13 Jun 2024 12:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1718306013; x=1718910813; 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=4G7tLL6hkkrYN5J6AmgB1cQMTV5U3cwwN/IX4PhnW2w=; b=UANJSgaGuCz1LggFKQpVRXQSDk5d6Qb2VDISrRdkanEjQ92eG46sa01LR8EI97ZT0G 1rWAV7PtVKEZH8pe3gklX+DfZcLpGowEwnBfPcIpRL41AjdXVz1HJW3UbzTQdH0mFIEi z7MmgKwtUfQere1qIv9oxFmYZOphxv7Gy2+kcIYDeQzbRqk40Phk62ExDQhcztddI6Io g55O5p5sZGptmuBfGEPVof1L8c2xVeLN4VfhFMxjmINaAi6cCc4BVMnlZS3d0/8JazqI WwGfSO0dbhvDlkpfkS4/7PE5IdQ7yNUis0HeKFB0eQKtYqoSMeMesgDXaShyClXpLb6z f/Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718306013; x=1718910813; 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=4G7tLL6hkkrYN5J6AmgB1cQMTV5U3cwwN/IX4PhnW2w=; b=PGr9A4pmQTW1ejJZkMjkhIoneyhYlU9eDcSddKd4RaYBu2C2EU1B8HiBzYgB7GixZx wyXGoJqkEpJ6JUUaSxqILprWmpncjo5OvQbB7s8qj4lFCnOzaGTHQv/BH737TxF3qtx8 t5lEWM1JwNtt6nT2znm72KBy2xCnvxRIb453QMlcqqpI6hZ7CgQp1RdA8nPeRKOradvV hvwhtNCBvYQJpCvQf0zf5BmE8I117zy+fy1w6ST5+4wMS6kzZnGJvL6qyikGcZlighH7 Wbr7HFDD+7j8BZAau8JqQ6Ml7fJodSMAWpr50m2J4HEVIwx1UXAR1SyKe/BDL58ULeHe 6X+w== X-Forwarded-Encrypted: i=1; AJvYcCXCQcq0LnfpIGGAXXCPE5V17cRTqClbeCTzwe8OrCkDOxxPoZJo7c/SY3F7xRZ/GXgd9gVoksjy4lvcGvNuj10= X-Gm-Message-State: AOJu0Yy8gO1BqJnz+etNZkYzGm9U1sHIEaRbNuaCmF202WoLhpx6m4ag 4rT4ZnlH7t+JMVfsAJjTQgIYJh5b7f3fcif8PyEZWjH/uOYo9xg2G38XH8nX1aY= X-Google-Smtp-Source: AGHT+IEyCcSaPkTFUw6paKzJVq7+2FHHZ9GjKCuO58qSm49imouvYSwd0+gtGISMAJewUpRUxmOCJg== X-Received: by 2002:a17:902:ea07:b0:1f7:1b52:f1a7 with SMTP id d9443c01a7336-1f862b15603mr6772415ad.51.1718306012636; Thu, 13 Jun 2024 12:13:32 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1f855f3c379sm17405335ad.272.2024.06.13.12.13.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Jun 2024 12:13:32 -0700 (PDT) Date: Thu, 13 Jun 2024 12:13:30 -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: <20240613121330.71538e19@hermes.local> In-Reply-To: <5a0370e4-aa42-4bc4-a5a8-34c37b88b95f@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> 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 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? Also would be better to use strtoul() instead of atoi() when parsing the args. That gives better error handling and handles someone passing negative number correctly.