From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 2893546128;
	Wed, 29 Jan 2025 18:17:44 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id AB2D940274;
	Wed, 29 Jan 2025 18:17:43 +0100 (CET)
Received: from mail-pj1-f44.google.com (mail-pj1-f44.google.com
 [209.85.216.44]) by mails.dpdk.org (Postfix) with ESMTP id 74A754026B
 for <dev@dpdk.org>; Wed, 29 Jan 2025 18:17:42 +0100 (CET)
Received: by mail-pj1-f44.google.com with SMTP id
 98e67ed59e1d1-2f44353649aso9577293a91.0
 for <dev@dpdk.org>; Wed, 29 Jan 2025 09:17:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1738171061;
 x=1738775861; 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=VK22RoLQAATpcgyostmeQvJbHLla+X9Ul3+GTsZzzGY=;
 b=ntAjg5ztd5y5XMQirXjjJnWkVMrxHCsioPbPxzlhxzvkPX7biRta5lpRYgU3+IwjW5
 tuozub6YRUCwuX6Esc9+XBIHgRswPviWizQYmhkKVQ1nbBydnoCfeOGVgY0cK6CWnnPi
 9g952jp+pUAP0cRPJMVIAyZSHmYzlipJevjwLzX+vEQfFnaauQ2HjAEQI8blI2mLPfI3
 tSLCErsb70pNOi4q9MJqcmBRegJ1ijjWf7+d3tOB/6Cjhj9Yi51ZYvKU/bW6vB4gtGLL
 xPsVOArXovpPmhOCA5i823gbS8COxR0Er3TF66u/LGj3KJXVp7IlZ4IPrWpUzNmI7dkS
 u/Qw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1738171061; x=1738775861;
 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=VK22RoLQAATpcgyostmeQvJbHLla+X9Ul3+GTsZzzGY=;
 b=utnIdRFsiW2qvQnC44t8+c2C1GeK7UR+nYPm7FMS47D4en5vciGOqX+TXw0K1B2yj6
 Ct1PUCCuIDLau9Vj2xfEyDIk6+Tdft6x3rxkRxqRv569Q6+TlmyBGk9KYuJLypwWNKqe
 8G0p7kztRsO6gBOLA/aCQYic9aIVuZOGe6HTo93pTPe7Lis6VlTxeRzbzjTap1v/RxAp
 Iake0EiRfVxPHmPQJEF6evSwKibkJxmuFVV0V3AXUwB7BLOG8J6bdVF3OnYm25HEDGE5
 VvGtqdnNCCsR5CCSBnOaarRM0cM/EGZCY/2H6FdGYSbxa/APh2wSFQ6O5/fANOP9e8Uw
 gN6w==
X-Gm-Message-State: AOJu0YzLCIPJPvi5j2bXKs9uiayrLjj1NQ4p1e60tI21U0zBx8Kb2Mg2
 O8KGRae+m/BkHlUAHaUg2vns8ROyypQM3boMfbJ35Q3i6fT4EtZ2qD13hADJj1E=
X-Gm-Gg: ASbGnct8XiPBXZJrZ+l3wzeEsUnSBqIifibWGeMRI+mhPURBIaIVY7QB2qI+itzGfm/
 HYrK+rsv5vmx154wF5SsoBDHKJPQ415lLqcq9VkaZKl8RNZAm5M+Y3E73meRoZ1zoUlNSRwi3yR
 AjufUuxbYuhZdwEsOxY76NKoc3SpkNNDS2KwYrCvV652Bctu6SJ7ySrQCU/CGd72bLUEmFOcu/T
 xxRaOli0dAzAqeO39uH9uyJJdO/KCPf69nvi/6bexyw/lcghrjuO215uMjgpvXkTPkBxxkZy7yp
 kt9HGiuaC5/jPL0yrwZfXkvXMinWxyNfu1ivmmJJPDLpmE++T8OUI+0hAAgl0lggrsox
X-Google-Smtp-Source: AGHT+IFBSYl4AZH4UYabbiegmzgYpXZq87pT+LNuLxtta8I0IeDxQGvet+0mWH2oFDSLYuYIAZqNlQ==
X-Received: by 2002:a17:90b:520d:b0:2ee:dd9b:e3e8 with SMTP id
 98e67ed59e1d1-2f83abd8adfmr5460018a91.8.1738171061424; 
 Wed, 29 Jan 2025 09:17:41 -0800 (PST)
Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226])
 by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-2f83be3622bsm2006650a91.46.2025.01.29.09.17.40
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 29 Jan 2025 09:17:41 -0800 (PST)
Date: Wed, 29 Jan 2025 09:17:38 -0800
From: Stephen Hemminger <stephen@networkplumber.org>
To: Shani Peretz <shperetz@nvidia.com>
Cc: <dev@dpdk.org>, <thomas@monjalon.net>, Tyler Retzlaff
 <roretzla@linux.microsoft.com>, Parav Pandit <parav@nvidia.com>, Xueming Li
 <xuemingl@nvidia.com>, Nipun Gupta <nipun.gupta@amd.com>, Nikhil Agarwal
 <nikhil.agarwal@amd.com>, Hemant Agrawal <hemant.agrawal@nxp.com>, "Sachin
 Saxena" <sachin.saxena@nxp.com>, Rosen Xu <rosen.xu@intel.com>, Chenbo Xia
 <chenbox@nvidia.com>, Tomasz Duszynski <tduszynski@marvell.com>, "Chengwen
 Feng" <fengchengwen@huawei.com>, Long Li <longli@microsoft.com>, Wei Hu
 <weh@microsoft.com>, Bruce Richardson <bruce.richardson@intel.com>, "Kevin
 Laatz" <kevin.laatz@intel.com>, Jan Blunck <jblunck@infradead.org>
Subject: Re: [PATCH v4] bus: fix inconsistent representation of PCI numbers
Message-ID: <20250129091738.681777f1@hermes.local>
In-Reply-To: <20250129085416.226718-1-shperetz@nvidia.com>
References: <20240708165145.1405107-1-shperetz@nvidia.com>
 <20250129085416.226718-1-shperetz@nvidia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org

On Wed, 29 Jan 2025 10:54:16 +0200
Shani Peretz <shperetz@nvidia.com> wrote:

> DPDK provides two formats for specifying PCI device numbers:
> a full version ("0000:08:00.0") and a short version ("08:00.0").
> Issues can occur when an application uses one format (e.g., short)
> while running testpmd, then attempts to use the other format
> (e.g., full) in a later command, resulting in a failure.
>=20
> The issue is that find_device goes over the list of devices and
> compares the user-provided string to the rte_device structure's
> device->name (device->name is just the string received from devargs
> (i.e "08:00.0" or "0000:08:00.0")).
> Notice that there's another field that represents the device name,
> but this one is in the rte_pci_bus struct. This name is actually the resu=
lt
> of the PCI parse function ("0000:08:00.0").
> If we want to accurately compare these names, we'll need to bring both
> sides to the same representation by invoking the parse function on
> the user input.
>=20
> To make the cmp_dev_name function applicable to all buses=E2=80=94not jus=
t PCI=E2=80=94
> the proposed solution is to utilize the parse function implemented by
> each bus. When comparing names, we will call parse on the supplied
> string as well as on the device name itself and compare the results.
> This will allow consistent comparisons between different representations
> of same devices.
>=20
> Also, the pci_common_set function has been modified to improve naming
> consistency for PCI buses.
> Now, the name stored in rte_device for PCI buses will match the parsed
> name that is also stored in rte_pci_device name,
> rather than using the user-provided string from devargs.
> As a result, when a new PCI device is registered, the name displayed in
> the device list will be the parsed version.
>=20
> Added tests that compare and find devices in various forms of names
> under test_devargs.
>=20
> Fixes: a3ee360f4440 ("eal: add hotplug add/remove device")

Maybe just fix for now by normalizing the PCI device string when before
storing and after parsing?  That would allow for simple fix that can be bac=
kported.
The more complex generalization of bus address is too much to go to stable =
branch.