From: "Charles (Chas) Williams" <3chas3@gmail.com>
To: "Richardson, Bruce" <bruce.richardson@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] devargs: add blacklisting by linux interface name
Date: Fri, 02 Oct 2015 14:29:27 -0400 [thread overview]
Message-ID: <1443810567.3494.45.camel@gmail.com> (raw)
In-Reply-To: <59AF69C657FD0841A61C55336867B5B03594BDB2@IRSMSX103.ger.corp.intel.com>
On Fri, 2015-10-02 at 16:44 +0000, Richardson, Bruce wrote:
> > -----Original Message-----
> > From: Charles (Chas) Williams [mailto:3chas3@gmail.com]
> >
> > On Fri, 2015-10-02 at 16:18 +0100, Bruce Richardson wrote:
> > > On Fri, Oct 02, 2015 at 11:00:07AM -0400, Chas Williams wrote:
> > > > If a system is using deterministic interface names, it may be easier
> > > > in some cases to use the interface name to blacklist an interface.
> > > >
> > >
> > > Is it possible to do this using the existing arguments, i.e. have the
> > > -b flag detect if it's a pci address or name automatically, rather
> > > than having to use a separate command-line arg for it?
> >
> > You might be able to distinguish names by context. I doubt interface
> > names ever look like PCI addresses. But that's going to be a bigger
> > change since -b will need to be updated to 'blacklist' intead of 'pci-
> > blacklist' to prevent confusion. Or do you just want to overload '-b' and
> > keep both long options?
> >
> I'm not sure about that, to be honest. However, I'd rather not have
> too many cmd line options to be maintained in the code.
>
> Does you proposed blacklisting patch work with non-pci devices as well
> as with PCI ones as now?
Unfortunately, the devargs API is rather PCI specific -- it takes a PCI
device. Nothing prevents you from writing a device specific version of
the devargs API though for your device class since the devargs list isn't
static but checking for certain devargs wouldn't make sense in some cases.
Checking to see if a USB device matched a blacklisted PCI device would
be pointless.
Other devices (like Xen or hyperv) have a net/ directory/link in their /sys
entry that lets you determine an interface name. I think it's the same
for USB ethernet devices -- I don't happen to have one to check.
next prev parent reply other threads:[~2015-10-02 18:29 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-02 15:00 Chas Williams
2015-10-02 15:18 ` Bruce Richardson
2015-10-02 16:38 ` Charles (Chas) Williams
2015-10-02 16:44 ` Richardson, Bruce
2015-10-02 18:29 ` Charles (Chas) Williams [this message]
2015-10-05 15:59 ` Charles (Chas) Williams
2015-10-05 15:26 ` [dpdk-dev] [PATCH v2] " Chas Williams
2015-10-06 7:35 ` Stephen Hemminger
2015-10-06 14:41 ` Charles (Chas) Williams
2015-10-13 12:49 ` Olivier MATZ
2015-10-14 13:41 ` Charles (Chas) Williams
2015-11-04 22:40 ` Thomas Monjalon
2015-11-05 16:39 ` Charles (Chas) Williams
2015-11-05 19:23 ` Stephen Hemminger
2015-11-10 18:51 ` Charles (Chas) Williams
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=1443810567.3494.45.camel@gmail.com \
--to=3chas3@gmail.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
/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).