DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Namburu, Chandu-babu" <chandu@amd.com>
To: David Marchand <david.marchand@redhat.com>
Cc: dev <dev@dpdk.org>,
	"Sebastian, Selwin" <Selwin.Sebastian@amd.com>,
	"Arsalan_Awan@mentor.com" <Arsalan_Awan@mentor.com>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>
Subject: RE: [PATCH v1] net/axgbe: use PCI root complex device to distinguish AMD hardware
Date: Thu, 2 Dec 2021 05:53:17 +0000	[thread overview]
Message-ID: <DM4PR12MB53445056266052BC8ADD358CC8699@DM4PR12MB5344.namprd12.prod.outlook.com> (raw)
In-Reply-To: <CAJFAV8z2Tm7LaEDPjTWMMZT8-rY7rN7N75VHV2HNu4E1oTxC+w@mail.gmail.com>

[Public]

Hi David Marchand,

Thank you for your comments. Will change patch and submit v2 for review

Regards,
Chandu

-----Original Message-----
From: David Marchand <david.marchand@redhat.com> 
Sent: Wednesday, December 1, 2021 2:31 PM
To: Namburu, Chandu-babu <chandu@amd.com>
Cc: dev <dev@dpdk.org>; Sebastian, Selwin <Selwin.Sebastian@amd.com>; Arsalan_Awan@mentor.com; Yigit, Ferruh <ferruh.yigit@intel.com>
Subject: Re: [PATCH v1] net/axgbe: use PCI root complex device to distinguish AMD hardware

On Fri, Nov 26, 2021 at 11:24 AM Chandubabu Namburu <chandu@amd.com> wrote:
>
> "bus/pci: optimize bus scan" broke axgbe on V1000/R1000.
> RV root complex pci device does not have any kernel driver assigned so 
> it is removed from pci scan list which is used in
> "net/axgbe: add a HW quirk for register definitions"
>
> Get root complex device id directly from pci sysfs instead of pci scan 
> list

Please end the sentences with a '.'.

As you described, this change is a fix.
Please add a Fixes: tag and Cc: stable@dpdk.org in the commitlog if you think it should be backported to LTS releases.
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc.dpdk.org%2Fguides%2Fcontributing%2Fpatches.html%23patch-for-stable-releases&amp;data=04%7C01%7Cchandu%40amd.com%7C6618c303ecb146be0b5908d9b4a91c01%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637739460691977618%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=piC1U%2BPcPP2A0xwM3%2FA5qDUFXNLAj2SrLBywTFc3DFM%3D&amp;reserved=0


>
> Signed-off-by: Chandubabu Namburu <chandu@amd.com>
> ---
>  drivers/net/axgbe/axgbe_ethdev.c | 39 
> ++++++++++++++++----------------
>  1 file changed, 20 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/net/axgbe/axgbe_ethdev.c 
> b/drivers/net/axgbe/axgbe_ethdev.c
> index 9cd056d04a..26babde354 100644
> --- a/drivers/net/axgbe/axgbe_ethdev.c
> +++ b/drivers/net/axgbe/axgbe_ethdev.c
> @@ -10,6 +10,8 @@
>  #include "axgbe_regs.h"
>  #include "rte_time.h"
>
> +#include "eal_filesystem.h"
> +
>  static int eth_axgbe_dev_init(struct rte_eth_dev *eth_dev);  static 
> int  axgbe_dev_configure(struct rte_eth_dev *dev);  static int  
> axgbe_dev_start(struct rte_eth_dev *dev); @@ -1923,28 +1925,27 @@ 
> static void axgbe_default_config(struct axgbe_port *pdata)
>         pdata->power_down = 0;
>  }
>
> -static int
> -pci_device_cmp(const struct rte_device *dev, const void *_pci_id)
> +/*
> + * Return PCI root complex device id on success else 0  */ static 
> +uint16_t
> +get_pci_rc_devid(void)
>  {
> -       const struct rte_pci_device *pdev = RTE_DEV_TO_PCI_CONST(dev);
> -       const struct rte_pci_id *pcid = _pci_id;
> +       char pci_sysfs[PATH_MAX];
> +       const struct rte_pci_addr pci_rc_addr = {0, 0, 0, 0};
> +       unsigned long device_id;
>
> -       if (pdev->id.vendor_id == AMD_PCI_VENDOR_ID &&
> -                       pdev->id.device_id == pcid->device_id)
> -               return 0;
> -       return 1;
> -}
> +       snprintf(pci_sysfs, sizeof(pci_sysfs), "%s/" PCI_PRI_FMT "/device",
> +                rte_pci_get_sysfs_path(), pci_rc_addr.domain,
> +                pci_rc_addr.bus, pci_rc_addr.devid, 
> + pci_rc_addr.function);

The use of rte_pci_get_sysfs_path() and in general is ugly because it only works for Linux.
We could come up with a better API in the pci bus, but I don't think it is worth it atm.

We can live with your implementation since this driver is only compiled on Linux.


--
David Marchand

  reply	other threads:[~2021-12-02  5:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-26 10:24 Chandubabu Namburu
2021-12-01  8:45 ` Awan, Arsalan
2021-12-01  9:00 ` David Marchand
2021-12-02  5:53   ` Namburu, Chandu-babu [this message]
2021-12-02 16:10 ` [PATCH v2] " Chandubabu Namburu
2021-12-22  9:27   ` Namburu, Chandu-babu
2022-01-10  6:38     ` Namburu, Chandu-babu
2022-01-17  5:40       ` Sebastian, Selwin
2022-01-17 10:22         ` Ferruh Yigit
2022-01-17 10:30           ` Sebastian, Selwin
2022-01-17 10:29         ` Sebastian, Selwin
2022-01-17 14:07           ` Ferruh Yigit

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=DM4PR12MB53445056266052BC8ADD358CC8699@DM4PR12MB5344.namprd12.prod.outlook.com \
    --to=chandu@amd.com \
    --cc=Arsalan_Awan@mentor.com \
    --cc=Selwin.Sebastian@amd.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.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).