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 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 ; Wed, 29 Jan 2025 18:17:42 +0100 (CET) Received: by mail-pj1-f44.google.com with SMTP id 98e67ed59e1d1-2f44353649aso9577293a91.0 for ; 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 To: Shani Peretz Cc: , , Tyler Retzlaff , Parav Pandit , Xueming Li , Nipun Gupta , Nikhil Agarwal , Hemant Agrawal , "Sachin Saxena" , Rosen Xu , Chenbo Xia , Tomasz Duszynski , "Chengwen Feng" , Long Li , Wei Hu , Bruce Richardson , "Kevin Laatz" , Jan Blunck 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Wed, 29 Jan 2025 10:54:16 +0200 Shani Peretz 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.