DPDK patches and discussions
 help / color / mirror / Atom feed
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
Date: Wed, 29 Jan 2025 09:17:38 -0800	[thread overview]
Message-ID: <20250129091738.681777f1@hermes.local> (raw)
In-Reply-To: <20250129085416.226718-1-shperetz@nvidia.com>

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.
> 
> 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.

  parent reply	other threads:[~2025-01-29 17:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-01 20:01 [PATCH] eal/common: " Shani Peretz
2024-07-01 22:00 ` Stephen Hemminger
2024-07-08 16:51 ` [PATCH v3] " Shani Peretz
2024-07-12 13:49   ` David Marchand
2024-07-12 17:55     ` Thomas Monjalon
2025-01-29  8:54   ` [PATCH v4] bus: " Shani Peretz
2025-01-29  9:45     ` Bruce Richardson
2025-01-29 16:25     ` Stephen Hemminger
2025-01-29 17:17     ` Stephen Hemminger [this message]
2025-01-29 18:06       ` Bruce Richardson
2024-10-04 22:21 ` [PATCH] eal/common: " Stephen Hemminger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250129091738.681777f1@hermes.local \
    --to=stephen@networkplumber.org \
    --cc=bruce.richardson@intel.com \
    --cc=chenbox@nvidia.com \
    --cc=dev@dpdk.org \
    --cc=fengchengwen@huawei.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=jblunck@infradead.org \
    --cc=kevin.laatz@intel.com \
    --cc=longli@microsoft.com \
    --cc=nikhil.agarwal@amd.com \
    --cc=nipun.gupta@amd.com \
    --cc=parav@nvidia.com \
    --cc=roretzla@linux.microsoft.com \
    --cc=rosen.xu@intel.com \
    --cc=sachin.saxena@nxp.com \
    --cc=shperetz@nvidia.com \
    --cc=tduszynski@marvell.com \
    --cc=thomas@monjalon.net \
    --cc=weh@microsoft.com \
    --cc=xuemingl@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).