From: "Van Haaren, Harry" <harry.van.haaren@intel.com>
To: "Gaëtan Rivet" <gaetan.rivet@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
Thomas Monjalon <thomas.monjalon@6wind.com>,
"Richardson, Bruce" <bruce.richardson@intel.com>
Subject: Re: [dpdk-dev] [PATCH v2 1/1] pci: default to whitelist mode
Date: Tue, 28 Mar 2017 13:02:13 +0000 [thread overview]
Message-ID: <E923DB57A917B54B9182A2E928D00FA612A208D2@IRSMSX102.ger.corp.intel.com> (raw)
In-Reply-To: <20170328124409.GC7450@bidouze.vm.6wind.com>
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Gaëtan Rivet
> Sent: Tuesday, March 28, 2017 1:44 PM
> To: Richardson, Bruce <bruce.richardson@intel.com>
> Cc: dev@dpdk.org; Thomas Monjalon <thomas.monjalon@6wind.com>
> Subject: Re: [dpdk-dev] [PATCH v2 1/1] pci: default to whitelist mode
>
> On Tue, Mar 28, 2017 at 01:20:00PM +0100, Bruce Richardson wrote:
> >On Tue, Mar 28, 2017 at 02:01:29PM +0200, Gaetan Rivet wrote:
> >> Expects all devices to be explicitly defined before being probed.
> >>
> >> The blacklist mode can be prone to errors, coaxing users in capturing
> >> devices that could be used for management or otherwise.
> >> The whitelist mode offers users more control and highlight mistakes by
> >> making them visible on the command line.
> >>
> >> This is more useful to have a clear idea of the state of the system used,
> >> which is better in the context of standalone / headless applications.
> >>
> >> Using the -b option will revert to the original behavior.
> >>
> >> Signed-off-by: Gaetan Rivet <gaetan.rivet@6wind.com>
> >> ---
> >> v2: justify this default behavior evolution.
> >> ---
> >
> >I don't have major objections to this patch, though it does make it
> >mandatory to use port parameters where before it was not. The one
> >suggestion I will make is that, if we take this approach, we should
> >probably add a --wl-all (whitelist-all) flag to go back to having all
> >ports automatically bound, if so desired.
> >
>
> Are there use cases where the blacklist mode would be used without
> blacklisting any device? The current -b option is almost enough for the
> same level of functionality.
>
> If there is an actual need to a full PCI probe, adding this option is
> certainly possible. I was thinking otherwise of allowing "all" as an
> argument to -w, which would have our users using -wall or -w=all, which
> seems clear enough.
If I understand correctly an app that runs without any port parameters to EAL would now fail to find any ports?
That would result in;
- testing frameworks (DTS, fd.io perf lab, customers, etc) would fail if not specifying ports
- beginners just running ./app/testpmd would need to specify the "magic" -w-all
- confusion about why previously working DPDK apps are now failing due to not finding any devices
I'm not totally opposed, but we should consider carefully what impacts this change will have across the whole DPDK ecosystem, and if the change is worth it. If decided that "Yes its worth it", we would need to communicate this change very clearly. All documentation regarding running any DPDK app would need to be updated as part of this change.
Personally I don't see the large benefit this patch brings, but more of a disturbance in the DPDK; I'm open to be convinced otherwise.
> This would essentially be the inverse of the
> --no-pci parameter.
>
> Which could probably be removed if this patch is accepted.
>
> --
> Gaëtan Rivet
> 6WIND
next prev parent reply other threads:[~2017-03-28 13:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-28 11:51 [dpdk-dev] [PATCH " Gaetan Rivet
2017-03-28 11:58 ` Bruce Richardson
2017-03-28 12:05 ` Gaëtan Rivet
2017-03-28 12:01 ` [dpdk-dev] [PATCH v2 " Gaetan Rivet
2017-03-28 12:20 ` Bruce Richardson
2017-03-28 12:44 ` Gaëtan Rivet
2017-03-28 13:02 ` Van Haaren, Harry [this message]
2017-03-28 13:53 ` Gaëtan Rivet
2017-03-30 19:36 ` Thomas Monjalon
2017-03-28 13:03 ` Bruce Richardson
2017-03-28 13:35 ` 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=E923DB57A917B54B9182A2E928D00FA612A208D2@IRSMSX102.ger.corp.intel.com \
--to=harry.van.haaren@intel.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=gaetan.rivet@6wind.com \
--cc=thomas.monjalon@6wind.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).