-----Original Message-----
From: dev <dev-boun...@dpdk.org> On Behalf Of Gaëtan Rivet
Sent: Wednesday, September 25, 2019 2:37 PM
To: Slava Ovsiienko <viachesl...@mellanox.com>
Cc: Vamsi Krishna Attunuru <vattun...@marvell.com>; dev@dpdk.org;
ferruh.yi...@intel.com; anatoly.bura...@intel.com; Thomas Monjalon
<tho...@monjalon.net>; Jerin Jacob Kollanukkaran <jer...@marvell.com>
Subject: Re: [dpdk-dev] [PATCH v1 1/1] bus/pci: probe PCI devices in
whitelisted order
On Wed, Sep 25, 2019 at 06:41:36AM +0000, Slava Ovsiienko wrote:
> > -----Original Message-----
> > From: dev <dev-boun...@dpdk.org> On Behalf Of vattun...@marvell.com
> > Sent: Monday, September 23, 2019 14:57
> > To: dev@dpdk.org
> > Cc: gaetan.ri...@6wind.com; ferruh.yi...@intel.com;
> > anatoly.bura...@intel.com; Thomas Monjalon <tho...@monjalon.net>;
> > jer...@marvell.com; Vamsi Attunuru <vattun...@marvell.com>
> > Subject: [dpdk-dev] [PATCH v1 1/1] bus/pci: probe PCI devices in
> > whitelisted order
> >
> > From: Vamsi Attunuru <vattun...@marvell.com>
> >
> > Current pci bus driver scans pci devices in the order that it read from
> > sysfs.
> > Accordingly all or whitelisted devices are getting probed.
> >
> > Patch modifies the probing order of whitelisted pci devices in a
> > sequence the devices are whitelisted(using EAL flags).
>
> Thanks, it would be nice to have opportunity to control probing order,
> it might be useful for bonded devices and representors either.
>
> Acked-by: Viacheslav Ovsiienko <viachesl...@mellanox.com>
>
> >
> > It ensures the eth devices that application uses are probed in
> > device whitelisted sequence, in turn it facilitates the packet
> > forwarding applications to work without any packet loss or
> > performance drop when the underneath network ports have different
> > bandwidths. By altering the whitelist order applications like
> > testpmd, l2fwd can forward the ingress traffic to egress port that has of
> > equivalent bandwidth.
> >
> > Signed-off-by: Vamsi Attunuru <vattun...@marvell.com>
Hello Vamsi, Viacheslav,
This is a nice patch. I agree that port dependency could be better handled. The
port-mapping part however should be managed at the app level.
Vamsi, you gave the example of l2fwd and testpmd, being able to properly
configure forwarding directions implicitly. I think the better approach here is
to add these configurations items within the apps directly. Configuring the
mapping at the port level is not precise enough. The proper control is about
cores, port and queues, not only ports.
This patch only solves a limited part of this issue with testpmd.
I wrote a command to do this, that collided with some stream rework from Intel
at the time (3, 4 years back?), so I did not take the time to force it through.
If there is a need we could discuss about adding this back. I had needed it to
write a PMD, that could be useful to others.
As you say Viacheslav, there are use-cases that will rely on fine-grained probe
order. However, this patch solves this issue only regarding PCI devices,
depending on other PCI devices. We have in EAL an improper hack about it,
forcing the vdev probe last, because usually ports depending on others are
virtual ones. As this patch shows, the hack is not sufficient, and as the hack
shows, this patch does not cover everything.
A solution, would be an EAL parameter (I propose --no-dev), that disable
probing for all buses. Applications and devices requiring a fine-grained probe
order, are then free to start in this mode (and maybe force it through EAL
conf), then hotplug ports as they see fit.
This will keep the existing behavior stable for current apps, while allowing
flexibility for the more advanced ones.
Hi Gaetan,
Thanks, vdev part was not taken care in this patch. Rather than imposing
hotplug for every application which requires port mapping, If vdev probing
order is also handled same as pdevs(in whitelist order), existing whitelisting
feature will serve the port mapping requirement, right. Also the existing
applications get benefited instead of overloading them with more configuration
options. If these probing order is not needed by default, it can be triggered
using an EAL parameter(not added yet).
Regards,
A Vamsi
--
Gaëtan Rivet
6WIND
