[v1] bus/pci: get PCI address from rte_device
Checks
Commit Message
From: Elena Agostini <eagostini@nvidia.com>
In DPDK 22.11 pci bus related structure have been hidden internally
so the application doesn't have a direct access to those info anymore.
This patch introduces a get function to retrieve a PCI address
from an rte_device handler.
Signed-off-by: Elena Agostini <eagostini@nvidia.com>
---
drivers/bus/pci/pci_common.c | 15 +++++++++++++++
drivers/bus/pci/rte_bus_pci.h | 13 +++++++++++++
2 files changed, 28 insertions(+)
Comments
30/05/2023 13:42, eagostini@nvidia.com:
> This patch introduces a get function to retrieve a PCI address
> from an rte_device handler.
[...]
> +const struct rte_pci_addr *
> +rte_pci_get_addr(const struct rte_device *dev)
> +{
> + const struct rte_pci_device *pci_dev;
> +
> + if (!dev) {
Please compare pointer with == NULL
> + rte_errno = EINVAL;
> + return NULL;
> + }
Can we check the bus type here?
> +
> + pci_dev = RTE_DEV_TO_PCI_CONST(dev);
> +
> + return &pci_dev->addr;
> +}
[...]
> +/**
> + * Return PCI device address of an rte_device
You can replace rte_device with "generic device" and add a dot :)
> + *
> + * @param dev
> + * A pointer to a rte_device structure describing the device
> + * to use
Do it simpler: pointer to the generic device structure.
> + *
> + * @return
> + * PCI address of the device on success, NULL if no driver
> + * is found for the device.
Not exactly, it can return NULL if the device is not PCI.
> + */
> +const struct rte_pci_addr * rte_pci_get_addr(const struct rte_device *dev);
On Tue, May 30, 2023 at 1:48 PM <eagostini@nvidia.com> wrote:
>
> From: Elena Agostini <eagostini@nvidia.com>
>
> In DPDK 22.11 pci bus related structure have been hidden internally
> so the application doesn't have a direct access to those info anymore.
>
> This patch introduces a get function to retrieve a PCI address
> from an rte_device handler.
>
> Signed-off-by: Elena Agostini <eagostini@nvidia.com>
(no need to Cc: stable, I removed it)
I would prefer we don't add specific bus API when there is an alternative.
The PCI address is already reported as a string in the generic device
object name.
I checked the different ways this name is set and afaics, it is consistent:
- devarg case https://git.dpdk.org/dpdk/tree/drivers/bus/pci/pci_common.c#n112
+ https://git.dpdk.org/dpdk/tree/drivers/bus/pci/pci_params.c#n117
- no devarg case
https://git.dpdk.org/dpdk/tree/drivers/bus/pci/pci_common.c#n115 +
https://git.dpdk.org/dpdk/tree/drivers/bus/pci/pci_common.c#n100
Would that be enough for your usecase?
> On Tue, May 30, 2023 at 1:48 PM eagostini@nvidia.com<mailto:eagostini@nvidia.com> wrote:
> >
> > From: Elena Agostini eagostini@nvidia.com<mailto:eagostini@nvidia.com>
> >
> > In DPDK 22.11 pci bus related structure have been hidden internally
> > so the application doesn't have a direct access to those info anymore.
> >
> > This patch introduces a get function to retrieve a PCI address
> > from an rte_device handler.
> >
> > Signed-off-by: Elena Agostini eagostini@nvidia.com<mailto:eagostini@nvidia.com>
>
> (no need to Cc: stable, I removed it)
>
> I would prefer we don't add specific bus API when there is an alternative.
>
> The PCI address is already reported as a string in the generic device
> object name.
> I checked the different ways this name is set and afaics, it is consistent:
> - devarg case https://git.dpdk.org/dpdk/tree/drivers/bus/pci/pci_common.c#n112
> + https://git.dpdk.org/dpdk/tree/drivers/bus/pci/pci_params.c#n117
> - no devarg case
> https://git.dpdk.org/dpdk/tree/drivers/bus/pci/pci_common.c#n115 +
> https://git.dpdk.org/dpdk/tree/drivers/bus/pci/pci_common.c#n100
>
> Would that be enough for your usecase?
No as I need to parse anyway the PCI address string in the form of domain/bus/devid/function.
DPDK already does it through a well-organized and exposed structure like rte_pci_addr.
Why not to use it?
Also, the device name can be changed as it’s exposed to application level.
>
>
> --
> David Marchand
On Wed, May 31, 2023 at 10:44 AM Elena Agostini <eagostini@nvidia.com> wrote:
>
> > On Tue, May 30, 2023 at 1:48 PM eagostini@nvidia.com wrote:
>
> > >
>
> > > From: Elena Agostini eagostini@nvidia.com
>
> > >
>
> > > In DPDK 22.11 pci bus related structure have been hidden internally
>
> > > so the application doesn't have a direct access to those info anymore.
>
> > >
>
> > > This patch introduces a get function to retrieve a PCI address
>
> > > from an rte_device handler.
>
> > >
>
> > > Signed-off-by: Elena Agostini eagostini@nvidia.com
>
> >
>
> > (no need to Cc: stable, I removed it)
>
> >
>
> > I would prefer we don't add specific bus API when there is an alternative.
>
> >
>
> > The PCI address is already reported as a string in the generic device
>
> > object name.
>
> > I checked the different ways this name is set and afaics, it is consistent:
>
> > - devarg case https://git.dpdk.org/dpdk/tree/drivers/bus/pci/pci_common.c#n112
>
> > + https://git.dpdk.org/dpdk/tree/drivers/bus/pci/pci_params.c#n117
>
> > - no devarg case
>
> > https://git.dpdk.org/dpdk/tree/drivers/bus/pci/pci_common.c#n115 +
>
> > https://git.dpdk.org/dpdk/tree/drivers/bus/pci/pci_common.c#n100
>
> >
>
> > Would that be enough for your usecase?
>
>
>
> No as I need to parse anyway the PCI address string in the form of domain/bus/devid/function.
I am curious. Can you explain why you would need such information?
>
> Also, the device name can be changed as it’s exposed to application level.
?
If you mean the application can bust the device name, well, it's the
application problem.
> On Wed, May 31, 2023 at 10:44 AM Elena Agostini eagostini@nvidia.com<mailto:eagostini@nvidia.com> wrote:
> >
> > > On Tue, May 30, 2023 at 1:48 PM eagostini@nvidia.com<mailto:eagostini@nvidia.com> wrote:
> >
> > > >
> >
> > > > From: Elena Agostini eagostini@nvidia.com<mailto:eagostini@nvidia.com>
> >
> > > >
> >
> > > > In DPDK 22.11 pci bus related structure have been hidden internally
> >
> > > > so the application doesn't have a direct access to those info anymore.
> >
> > > >
> >
> > > > This patch introduces a get function to retrieve a PCI address
> >
> > > > from an rte_device handler.
> >
> > > >
> >
> > > > Signed-off-by: Elena Agostini eagostini@nvidia.com<mailto:eagostini@nvidia.com>
> >
> > >
> >
> > > (no need to Cc: stable, I removed it)
> >
> > >
> >
> > > I would prefer we don't add specific bus API when there is an alternative.
> >
> > >
> >
> > > The PCI address is already reported as a string in the generic device
> >
> > > object name.
> >
> > > I checked the different ways this name is set and afaics, it is consistent:
> >
> > > - devarg case https://git.dpdk.org/dpdk/tree/drivers/bus/pci/pci_common.c#n112
> >
> > > + https://git.dpdk.org/dpdk/tree/drivers/bus/pci/pci_params.c#n117
> >
> > > - no devarg case
> >
> > > https://git.dpdk.org/dpdk/tree/drivers/bus/pci/pci_common.c#n115 +
> >
> > > https://git.dpdk.org/dpdk/tree/drivers/bus/pci/pci_common.c#n100
> >
> > >
> >
> > > Would that be enough for your usecase?
> >
> >
> >
> > No as I need to parse anyway the PCI address string in the form of domain/bus/devid/function.>
> I am curious. Can you explain why you would need such information?>
Use-case is the Aerial 5G where two processes have to exchange info
about PCI devices sending messages according to some specific format.
> >
> > Also, the device name can be changed as it’s exposed to application level.>
> ?
> If you mean the application can bust the device name, well, it's the
> application problem.>
>
> --
> David Marchand
(I reformatted the mail a bit)
On Wed, May 31, 2023 at 10:51 AM Elena Agostini <eagostini@nvidia.com> wrote:
> > On Wed, May 31, 2023 at 10:44 AM Elena Agostini eagostini@nvidia.com wrote:
> > > > On Tue, May 30, 2023 at 1:48 PM eagostini@nvidia.com wrote:
> > > > > From: Elena Agostini eagostini@nvidia.com
> > > > > In DPDK 22.11 pci bus related structure have been hidden internally
> > > > > so the application doesn't have a direct access to those info anymore.
> > > > > This patch introduces a get function to retrieve a PCI address
> > > > > from an rte_device handler.
> > > > > Signed-off-by: Elena Agostini eagostini@nvidia.com
> > > > I would prefer we don't add specific bus API when there is an alternative.
> > > > The PCI address is already reported as a string in the generic device
> > > > object name.
> > > > Would that be enough for your usecase?
> > > No as I need to parse anyway the PCI address string in the form of domain/bus/devid/function.
> > I am curious. Can you explain why you would need such information?
> Use-case is the Aerial 5G where two processes have to exchange info
> about PCI devices sending messages according to some specific format.
It seems strange that different processes need to exchange this bus
level information.
For dataplane, having a simpler metadata (like a portid maybe?) is
better than a domain/bus/devid/function quartet.
For controlplane, having an abstraction or a human readable string is
probably better too.
In any case, for what you request here, the application can parse the
generic device name into a rte_pci_addr via rte_pci_addr_parse().
Is it not enough?
On Wed, May 31, 2023 at 11:52 AM David Marchand
<david.marchand@redhat.com> wrote:
>
> (I reformatted the mail a bit)
>
> On Wed, May 31, 2023 at 10:51 AM Elena Agostini <eagostini@nvidia.com> wrote:
> > > On Wed, May 31, 2023 at 10:44 AM Elena Agostini eagostini@nvidia.com wrote:
> > > > > On Tue, May 30, 2023 at 1:48 PM eagostini@nvidia.com wrote:
> > > > > > From: Elena Agostini eagostini@nvidia.com
> > > > > > In DPDK 22.11 pci bus related structure have been hidden internally
> > > > > > so the application doesn't have a direct access to those info anymore.
> > > > > > This patch introduces a get function to retrieve a PCI address
> > > > > > from an rte_device handler.
> > > > > > Signed-off-by: Elena Agostini eagostini@nvidia.com
>
> > > > > I would prefer we don't add specific bus API when there is an alternative.
> > > > > The PCI address is already reported as a string in the generic device
> > > > > object name.
> > > > > Would that be enough for your usecase?
>
> > > > No as I need to parse anyway the PCI address string in the form of domain/bus/devid/function.
>
> > > I am curious. Can you explain why you would need such information?
>
> > Use-case is the Aerial 5G where two processes have to exchange info
> > about PCI devices sending messages according to some specific format.
>
> It seems strange that different processes need to exchange this bus
> level information.
> For dataplane, having a simpler metadata (like a portid maybe?) is
> better than a domain/bus/devid/function quartet.
> For controlplane, having an abstraction or a human readable string is
> probably better too.
>
> In any case, for what you request here, the application can parse the
> generic device name into a rte_pci_addr via rte_pci_addr_parse().
> Is it not enough?
No reply for some time now, marking this patch as rejected.
@@ -884,6 +884,21 @@ rte_pci_set_bus_master(struct rte_pci_device *dev, bool enable)
return 0;
}
+const struct rte_pci_addr *
+rte_pci_get_addr(const struct rte_device *dev)
+{
+ const struct rte_pci_device *pci_dev;
+
+ if (!dev) {
+ rte_errno = EINVAL;
+ return NULL;
+ }
+
+ pci_dev = RTE_DEV_TO_PCI_CONST(dev);
+
+ return &pci_dev->addr;
+}
+
struct rte_pci_bus rte_pci_bus = {
.bus = {
.scan = rte_pci_scan,
@@ -68,6 +68,19 @@ void rte_pci_unmap_device(struct rte_pci_device *dev);
*/
void rte_pci_dump(FILE *f);
+/**
+ * Return PCI device address of an rte_device
+ *
+ * @param dev
+ * A pointer to a rte_device structure describing the device
+ * to use
+ *
+ * @return
+ * PCI address of the device on success, NULL if no driver
+ * is found for the device.
+ */
+const struct rte_pci_addr * rte_pci_get_addr(const struct rte_device *dev);
+
/**
* Find device's extended PCI capability.
*