On Wed, 29 Jan 2025 10:54:16 +0200
Shani Peretz <shper...@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.
> 
> 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 result
> 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.
> 
> To make the cmp_dev_name function applicable to all buses—not just PCI—
> 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.
> 
> 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.
> 
> Added tests that compare and find devices in various forms of names
> under test_devargs.
> 
> 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 
backported.
The more complex generalization of bus address is too much to go to stable 
branch.

Reply via email to