From: Vamsi Krishna Attunuru <vattunuru@marvell.com>
To: "Gaëtan Rivet" <gaetan.rivet@6wind.com>
Cc: Slava Ovsiienko <viacheslavo@mellanox.com>,
"dev@dpdk.org" <dev@dpdk.org>,
"ferruh.yigit@intel.com" <ferruh.yigit@intel.com>,
"anatoly.burakov@intel.com" <anatoly.burakov@intel.com>,
Thomas Monjalon <thomas@monjalon.net>,
Jerin Jacob Kollanukkaran <jerinj@marvell.com>
Subject: Re: [dpdk-dev] [EXT] Re: [PATCH v1 1/1] bus/pci: probe PCI devices in whitelisted order
Date: Thu, 26 Sep 2019 09:39:59 +0000 [thread overview]
Message-ID: <MWHPR18MB164529024209BC841486C826A6860@MWHPR18MB1645.namprd18.prod.outlook.com> (raw)
In-Reply-To: <20190926080402.xl6ibg6yvoyobcyh@bidouze.vm.6wind.com>
> -----Original Message-----
> From: Gaëtan Rivet <gaetan.rivet@6wind.com>
> Sent: Thursday, September 26, 2019 1:34 PM
> To: Vamsi Krishna Attunuru <vattunuru@marvell.com>
> Cc: Slava Ovsiienko <viacheslavo@mellanox.com>; dev@dpdk.org;
> ferruh.yigit@intel.com; anatoly.burakov@intel.com; Thomas Monjalon
> <thomas@monjalon.net>; Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> Subject: [EXT] Re: [dpdk-dev] [PATCH v1 1/1] bus/pci: probe PCI devices in
> whitelisted order
>
> External Email
>
> ----------------------------------------------------------------------
> On Thu, Sep 26, 2019 at 04:15:49AM +0000, Vamsi Krishna Attunuru wrote:
> >
> >
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Gaëtan Rivet
> > Sent: Wednesday, September 25, 2019 2:37 PM
> > To: Slava Ovsiienko <viacheslavo@mellanox.com>
> > Cc: Vamsi Krishna Attunuru <vattunuru@marvell.com>; dev@dpdk.org;
> > ferruh.yigit@intel.com; anatoly.burakov@intel.com; Thomas Monjalon
> > <thomas@monjalon.net>; Jerin Jacob Kollanukkaran <jerinj@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-bounces@dpdk.org> On Behalf Of
> > > > vattunuru@marvell.com
> > > > Sent: Monday, September 23, 2019 14:57
> > > > To: dev@dpdk.org
> > > > Cc: gaetan.rivet@6wind.com; ferruh.yigit@intel.com;
> > > > anatoly.burakov@intel.com; Thomas Monjalon <thomas@monjalon.net>;
> > > > jerinj@marvell.com; Vamsi Attunuru <vattunuru@marvell.com>
> > > > Subject: [dpdk-dev] [PATCH v1 1/1] bus/pci: probe PCI devices in
> > > > whitelisted order
> > > >
> > > > From: Vamsi Attunuru <vattunuru@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 <viacheslavo@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 <vattunuru@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
>
> Hi,
>
> The way buses are written right now, they will each do a whole scan, then they
> each probe all their devices.
>
> You cannot intersperse probes across several buses, i.e. probe a PCI device, then
> a vdev, then another PCI device.
>
> Changing this structure could be difficult. A possible way to do what you want
> without breaking everything would be to do what the app would have done in
> my solution above, but from within the EAL: block all probes, then go over a
> mixed list of (-w) and (--vdev) parameters and hotplug them in order. This would
> require the --no-dev (or --no-probe, or --no-auto-probe) flag anyway (or as a
> conf item, or something at least telling the EAL to behave this way).
>
> Would this way of doing it work for you?
Yes, above approach sounds fine to me and it works without breaking everything.
>
> In any case, controlling the probe order should be fixed properly for all buses
> and the general use-case if possible, instead of limiting the patch to the PCI bus.
Ack
>
> Kind regards,
> --
> Gaëtan Rivet
> 6WIND
next prev parent reply other threads:[~2019-09-26 9:41 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-23 11:56 [dpdk-dev] " vattunuru
2019-09-25 6:41 ` Slava Ovsiienko
2019-09-25 9:07 ` Gaëtan Rivet
2019-09-26 4:15 ` Vamsi Krishna Attunuru
2019-09-26 8:04 ` Gaëtan Rivet
2019-09-26 9:39 ` Vamsi Krishna Attunuru [this message]
2019-09-30 12:51 ` [dpdk-dev] [PATCH v1] eal: add manual probing option Gaetan Rivet
2019-09-30 17:51 ` Aaron Conole
2019-10-01 7:28 ` Gaëtan Rivet
2019-10-01 12:57 ` Aaron Conole
2019-09-30 18:53 ` Stephen Hemminger
2019-10-01 9:10 ` Gaëtan Rivet
2019-10-01 9:49 ` Jerin Jacob
2019-10-01 14:09 ` Gaëtan Rivet
2019-10-01 14:26 ` Jerin Jacob
2019-10-03 7:58 ` [dpdk-dev] [PATCH v2] " Gaetan Rivet
2019-10-04 12:55 ` [dpdk-dev] [PATCH v3] " Gaetan Rivet
2019-10-07 1:27 ` Vamsi Krishna Attunuru
2019-10-23 8:44 ` Gaëtan Rivet
2019-10-25 11:59 ` Jerin Jacob
2019-10-25 12:50 ` Gaëtan Rivet
2019-10-25 13:24 ` Jerin Jacob
2019-10-25 14:41 ` [dpdk-dev] [PATCH v4] " Gaetan Rivet
2019-10-25 15:01 ` Jerin Jacob
2019-10-25 15:46 ` [dpdk-dev] [PATCH v5] " Gaetan Rivet
2019-10-25 15:51 ` Jerin Jacob
2020-01-22 16:51 ` Pavan Nikhilesh Bhagavatula
2020-01-23 9:20 ` Gaetan Rivet
2020-01-23 9:58 ` [dpdk-dev] [PATCH v7] " Gaetan Rivet
2020-02-03 5:16 ` Pavan Nikhilesh Bhagavatula
2020-02-03 22:21 ` Thomas Monjalon
2020-02-04 10:03 ` Gaetan Rivet
2020-02-04 11:07 ` Thomas Monjalon
2020-02-04 12:43 ` Gaetan Rivet
2020-02-04 15:06 ` Thomas Monjalon
2020-02-04 16:02 ` Gaetan Rivet
2020-02-10 14:51 ` Jerin Jacob
2020-02-10 15:27 ` Thomas Monjalon
2020-02-10 16:33 ` Jerin Jacob
2020-04-03 3:30 ` [dpdk-dev] [PATCH] [v1 1/1] examples/l2fwd: add cmdline option for forwarding port info vattunuru
2020-04-03 12:51 ` Andrzej Ostruszka [C]
2020-04-05 3:49 ` Vamsi Krishna Attunuru
2020-04-05 3:52 ` [dpdk-dev] [PATCH] [v2 " vattunuru
2020-04-06 9:32 ` Andrzej Ostruszka [C]
2020-04-26 21:19 ` Thomas Monjalon
2020-04-27 7:59 ` [dpdk-dev] [PATCH v3] " pbhagavatula
2020-04-27 9:19 ` Sunil Kumar Kori
2020-04-27 9:36 ` Andrzej Ostruszka [C]
2020-04-27 10:14 ` Sunil Kumar Kori
2020-04-27 16:38 ` Pavan Nikhilesh Bhagavatula
2020-04-27 16:49 ` Sunil Kumar Kori
2020-04-27 18:31 ` [dpdk-dev] [PATCH v4] " pbhagavatula
2020-04-28 5:54 ` Sunil Kumar Kori
2020-05-01 14:00 ` Varghese, Vipin
2020-05-01 15:14 ` Pavan Nikhilesh Bhagavatula
2020-05-02 4:34 ` Varghese, Vipin
2020-05-11 0:23 ` Pavan Nikhilesh Bhagavatula
2020-05-24 16:13 ` Thomas Monjalon
2020-05-25 9:29 ` Bruce Richardson
2020-07-04 13:36 ` Jerin Jacob
2020-07-05 12:23 ` Thomas Monjalon
2020-04-04 16:34 ` [dpdk-dev] [EXT] Re: [PATCH v7] eal: add manual probing option Jerin Jacob Kollanukkaran
2023-06-14 19:33 ` [dpdk-dev] " Stephen Hemminger
2023-06-26 16:12 ` 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=MWHPR18MB164529024209BC841486C826A6860@MWHPR18MB1645.namprd18.prod.outlook.com \
--to=vattunuru@marvell.com \
--cc=anatoly.burakov@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=gaetan.rivet@6wind.com \
--cc=jerinj@marvell.com \
--cc=thomas@monjalon.net \
--cc=viacheslavo@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).