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 403A44541F; Thu, 13 Jun 2024 21:13:35 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1540B402E4; Thu, 13 Jun 2024 21:13:35 +0200 (CEST) Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) by mails.dpdk.org (Postfix) with ESMTP id BA51E402CF for ; Thu, 13 Jun 2024 21:13:33 +0200 (CEST) Received: by mail-pl1-f172.google.com with SMTP id d9443c01a7336-1f6b0a40721so10270935ad.2 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=AD4Gm6OzeddhNr2KazzQuiEH5Op6SQIW3mxjS1K75p8nvs4iZIWN9DmBtPF/g0rUQm +wil1hzow9Wulthwxh5C74+EIBye0skxVrLLpuCG8qLEObO+JguLhoU0o+BkaxuNfTST 2cFXfcGCma28JlEoRioy/rfdCB/mytTKXIvyc8yatQx3iG+WVEC2x6bKamBDqvgLJ+gs EFOjhV6m0TncT6aN0CG5G+95y4A+zZXpnpLJJi9XFFy8Rl/9B769DHzOKYnSP8k46Ieu hF+ffOSD2oAzmr3wzIUIpdkBy7lA8MWx9lDZQ0aqbb9vx78p8R1X+WsPFhpJXE7DmKWE 1f1w== X-Forwarded-Encrypted: i=1; AJvYcCUn8pzjMTCb4S1zNgIOVexzt2GoKlkpEyk8lhj0JKIQKvOTz+SndC+vnVU4Er3qOCCaI/UluE3mrH9TKDA= X-Gm-Message-State: AOJu0YwMKiY0GOhiLcSUOaCHkGjCR+zlMaFWlhG+w86H2Xibtw9gVz6o hO38/oYb1PyB/dnMY5bCMAaf1LJz85Cgk3OS9Rkbc0WBswgmFTGsjo3N1McmVEA= 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: 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 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.