From: "Gaëtan Rivet" <gaetan.rivet@6wind.com>
To: "Van Haaren, Harry" <harry.van.haaren@intel.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 15:53:41 +0200 [thread overview]
Message-ID: <20170328135341.GF7450@bidouze.vm.6wind.com> (raw)
In-Reply-To: <E923DB57A917B54B9182A2E928D00FA612A208D2@IRSMSX102.ger.corp.intel.com>
On Tue, Mar 28, 2017 at 01:02:13PM +0000, Van Haaren, Harry wrote:
>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
Yes, sure. There are certainly people who would be impacted. I'd be
curious however to hear from them and know exactly how many are using
the blacklist mode.
If I am writing a test for a device usually I explicitly specify the
device and the corresponding topology. This always results in whitelist
parameters. I can certainly imagine other people working differently.
>- beginners just running ./app/testpmd would need to specify the "magic" -w-all
Remembering starting with DPDK a few years back, I was actually confused
a few times by needing to blacklist a few devices. The DPDK
use case is extremely specific and my first intuition was that I'd
have to assign specific ports.
The blacklist mode was pretty much justified to me at the time as an
historic cruft left there because no one wanted the hassle of removing
it. I have never used it personally, so I'd be curious to hear about
other users that would design their tests and application to rely on
this blacklist mode.
>- 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.
>
Ah sure, it won't happen overnight. It would be coming no sooner than
17.08, even maybe 17.11. It would have several deprecation notices for
parameters that would change or disappear, and indeed the documentation
should be updated in many places.
I'm all for it personally.
--
Gaëtan Rivet
6WIND
next prev parent reply other threads:[~2017-03-28 13:53 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
2017-03-28 13:53 ` Gaëtan Rivet [this message]
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=20170328135341.GF7450@bidouze.vm.6wind.com \
--to=gaetan.rivet@6wind.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=harry.van.haaren@intel.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).