From: Or Gerlitz <or.gerlitz@gmail.com>
To: Ben Hutchings <bhutchings@solarflare.com>,
John Fastabend <john.r.fastabend@intel.com>,
David Miller <davem@davemloft.net>
Cc: Or Gerlitz <ogerlitz@mellanox.com>,
netdev@vger.kernel.org, amirv@mellanox.com, ronye@mellanox.com
Subject: Re: [PATCH RFC 0/2] Control VF link state
Date: Mon, 20 May 2013 23:06:20 +0300 [thread overview]
Message-ID: <CAJZOPZ+c4HDbd+983qosp+NOmpZ-U3sCWKyKZrEVW_UDhfMEWA@mail.gmail.com> (raw)
In-Reply-To: <1368146064.4131.279.camel@deadeye.wl.decadent.org.uk>
On Fri, May 10, 2013 at 3:34 AM, Ben Hutchings
<bhutchings@solarflare.com> wrote:
> Yeah. In some ways it could be better for a PF driver to create two net
> devices, one which acts as a vswitch port and one which bypasses it (if
> possible). But then that's going to confuse people too. I don't think we can win...
>>> Perhaps the default should also be specified?
So can we make progress in steps here... e.g deal with the question
whether the PF exposes one or two netdevices in a future thread and
add now code supporting an admin ability to control VF link state (I
suggest for the default, e.g when no config directive was applied to
be "auto" means follow the PF link state, as was suggested here)? if
we agree on that, do we want new ndo_set_vf_ call or introducr
ndo_set_vf_config call which whose param will be further extended each
time we add new feature to control/configure?
Or.
next prev parent reply other threads:[~2013-05-20 20:06 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-08 13:45 [PATCH RFC 0/2] Control VF link state Or Gerlitz
2013-05-08 13:45 ` [PATCH RFC 1/2] net/core: Add netlink directives to control " Or Gerlitz
2013-05-08 16:02 ` Sergei Shtylyov
2013-06-09 9:51 ` Or Gerlitz
2013-05-08 13:45 ` [PATCH RFC 2/2] net/mlx4: Add vf link state support Or Gerlitz
2013-05-08 13:45 ` [PATCH RFC iproute2] Add VF link state control Or Gerlitz
2013-05-08 16:17 ` Stephen Hemminger
2013-05-08 16:24 ` Dan Williams
2013-05-08 16:44 ` John Fastabend
2013-05-08 17:31 ` Or Gerlitz
2013-05-09 8:34 ` Or Gerlitz
2013-05-09 15:24 ` [PATCH RFC 0/2] Control VF link state Ben Hutchings
2013-05-09 23:17 ` Or Gerlitz
2013-05-10 0:34 ` Ben Hutchings
2013-05-12 21:48 ` Or Gerlitz
2013-05-14 17:12 ` Ben Hutchings
2013-05-14 19:59 ` John Fastabend
2013-05-20 20:06 ` Or Gerlitz [this message]
2013-05-20 20:37 ` Ben Hutchings
2013-05-21 20:12 ` Or Gerlitz
2013-05-21 21:43 ` John Fastabend
2013-06-09 13:27 ` Or Gerlitz
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=CAJZOPZ+c4HDbd+983qosp+NOmpZ-U3sCWKyKZrEVW_UDhfMEWA@mail.gmail.com \
--to=or.gerlitz@gmail.com \
--cc=amirv@mellanox.com \
--cc=bhutchings@solarflare.com \
--cc=davem@davemloft.net \
--cc=john.r.fastabend@intel.com \
--cc=netdev@vger.kernel.org \
--cc=ogerlitz@mellanox.com \
--cc=ronye@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).