From: Thomas Monjalon <thomas@monjalon.net>
To: gowrishankar muthukrishnan <gowrishankar.m@linux.vnet.ibm.com>
Cc: dev@dpdk.org, "Gaëtan Rivet" <gaetan.rivet@6wind.com>,
"Declan Doherty" <declan.doherty@intel.com>,
"Ferruh Yigit" <ferruh.yigit@intel.com>,
rasland@mellanox.com
Subject: Re: [dpdk-dev] [PATCH v2] net/bonding: support bifurcated driver in eal cli using --vdev
Date: Tue, 05 Sep 2017 11:13:00 +0200 [thread overview]
Message-ID: <19317053.0GOQUN8yPN@xps> (raw)
In-Reply-To: <20170731143458.GL11154@bidouze.vm.6wind.com>
Ping - any news?
31/07/2017 16:34, Gaëtan Rivet:
> Hi Gowrishankar, Declan,
>
> On Mon, Jul 10, 2017 at 12:02:24PM +0530, gowrishankar muthukrishnan wrote:
> > On Friday 07 July 2017 09:08 PM, Declan Doherty wrote:
> > >On 04/07/2017 12:57 PM, Gowrishankar wrote:
> > >>From: Gowrishankar Muthukrishnan <gowrishankar.m@linux.vnet.ibm.com>
> > >>
> > >>At present, creating bonding devices using --vdev is broken for PMD like
> > >>mlx5 as it is neither UIO nor VFIO based and hence PMD driver is unknown
> > >>to find_port_id_by_pci_addr(), as below.
> > >>
> > >>testpmd <EAL args> --vdev 'net_bonding0,mode=1,slave=<PCI>,socket_id=0'
> > >>
> > >>PMD: bond_ethdev_parse_slave_port_kvarg(150) - Invalid slave port value
> > >> (<PCI ID>) specified
> > >>EAL: Failed to parse slave ports for bonded device net_bonding0
> > >>
> > >>This patch fixes parsing PCI ID from bonding device params by verifying
> > >>it in RTE PCI bus, rather than checking dev->kdrv.
> > >>
> > >>Changes:
> > >> v2 - revisit fix by iterating rte_pci_bus
> > >>
> > >>Signed-off-by: Gowrishankar Muthukrishnan
> > >><gowrishankar.m@linux.vnet.ibm.com>
> > >>---
> > >...
> > >>
> > >
> > >Hey Gowrishankar,
> > >
> > >I was having a look at this patch and there is the following checkpatch
> > >error.
> > >
> > >_coding style issues_
> > >
> > >
> > >WARNING:AVOID_EXTERNS: externs should be avoided in .c files
> > >#48: FILE: drivers/net/bonding/rte_eth_bond_args.c:43:
> > >+extern struct rte_pci_bus rte_pci_bus;
> > >
> > Hi Declan,
> > Thank you for your review.
> > Yes, but I also saw some references like above in older code.
> >
> > >
> > >Looking at bit closer at the issue I think there is a simpler solution,
> > >the bonding driver really shouldn't be parsing the PCI bus directly, and
> > >since PCI devices use the PCI DBF as their name we can simply replace the
> > >all the scanning code with a simple call to rte_eth_dev_get_port_by_name
> > >API.
> > >
>
> I agree that it would be better to be able to use the ether API for
> this.
>
> The issue is that PCI devices are inconsistent regarding their names. The
> possibility is given to the user to employ the simplified BDF format for
> PCI device name, instead of the DomBDF format.
>
> Unfortunately, the default device name for a PCI device is in the DomBDF
> format. This means that the name won't match if the device was probed by
> using the PCI blacklist mode (the default PCI mode).
>
> The matching must be refined.
>
> >
> > But you are removing an option to mention ports by PCI addresses right (as
> > I see parse_port_id() completely removed in your patch) ?.
> > IMO, we just need to check if given eth pci id (incase we mention ports ib
> > PCI ID) is one of what EAL scanned in PCI. Also, slaves should not be from
> > any blacklisted PCI ids (as we test with -b or -w).
> >
>
> Declan is right about the iteration of PCI devices. The device list for
> the PCI bus is private, the extern declaration to the rte_pci_bus is the
> telltale sign that there is something wrong in the approach here.
>
> In order to respect the new rte_bus logic, I think what you want to
> achieve can be done by using the rte_bus->find_device with the correct
> device comparison function.
>
> static int
> pci_addr_cmp(const struct rte_device *dev, const void *_pci_addr)
> {
> struct rte_pci_device *pdev;
> char *addr = _pci_addr;
> struct rte_pci_addr paddr;
> static struct rte_bus *pci_bus = NULL;
>
> if (pci_bus == NULL)
> pci_bus = rte_bus_find_by_name("pci");
>
> if (pci_bus->parse(addr, &paddr) != 0) {
> /* Invalid PCI addr given as input. */
> return -1;
> }
> pdev = RTE_DEV_TO_PCI(dev);
> return rte_eal_compare_pci_addr(&pdev->addr, &paddr);
> }
>
> Then verify that you are able to get a device by using it as follows:
>
> {
> struct rte_bus *pci_bus;
> struct rte_device *dev;
>
> pci_bus = rte_bus_find_by_name("pci");
> if (pci_bus == NULL) {
> RTE_LOG(ERR, PMD, "Unable to find PCI bus\n");
> return -1;
> }
> dev = pci_bus->find_device(NULL, pci_addr_cmp, devname);
> if (dev == NULL) {
> RTE_LOG(ERR, PMD, "Unable to find the device %s to enslave.\n",
> devname);
> return -EINVAL;
> }
> }
>
> I hope it's clear enough. You can find examples of use for this API in
> lib/librte_eal/common/eal_common_dev.c
>
> It's a quick implementation to outline the possible direction, I
> haven't compiled it. It should be refined.
>
> For example, the PCI address validation should not be happening in the
> comparison function, the pci_bus could be matched once instead of twice,
> etc...
>
> But the logic should work.
>
> Best regards,
>
next prev parent reply other threads:[~2017-09-05 9:13 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-14 10:49 [dpdk-dev] [PATCH] " Gowrishankar
2017-06-15 13:54 ` Ferruh Yigit
2017-06-16 14:34 ` Thomas Monjalon
2017-07-04 11:57 ` [dpdk-dev] [PATCH v2] " Gowrishankar
2017-07-07 15:38 ` Declan Doherty
2017-07-10 6:32 ` gowrishankar muthukrishnan
2017-07-31 14:34 ` Gaëtan Rivet
2017-09-05 9:13 ` Thomas Monjalon [this message]
2017-09-06 8:59 ` gowrishankar muthukrishnan
2017-10-02 8:41 ` [dpdk-dev] [Suspected-Phishing]Re: " Raslan Darawsheh
2017-10-02 8:44 ` gowrishankar muthukrishnan
2017-10-03 8:38 ` [dpdk-dev] [Suspected-Phishing]Re: " Raslan Darawsheh
2017-09-20 18:04 ` [dpdk-dev] [PATCH v3] " Gowrishankar
2017-10-02 11:06 ` Doherty, Declan
2017-10-02 23:32 ` Ferruh Yigit
2017-10-02 12:09 ` Gaëtan Rivet
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=19317053.0GOQUN8yPN@xps \
--to=thomas@monjalon.net \
--cc=declan.doherty@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=gaetan.rivet@6wind.com \
--cc=gowrishankar.m@linux.vnet.ibm.com \
--cc=rasland@mellanox.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).