netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ben Hutchings <bhutchings@solarflare.com>
To: John Fastabend <john.fastabend@gmail.com>
Cc: <Narendra_K@Dell.com>, <netdev@vger.kernel.org>,
	<john.r.fastabend@intel.com>
Subject: Re: [PATCH net-next] net: Add phys_port identifier to struct net_device and export it to sysfs
Date: Fri, 28 Jun 2013 18:09:13 +0100	[thread overview]
Message-ID: <1372439353.1937.21.camel@bwh-desktop.uk.level5networks.com> (raw)
In-Reply-To: <51CDBAE9.1020807@gmail.com>

On Fri, 2013-06-28 at 09:33 -0700, John Fastabend wrote:
> [...]
> 
> >>
> >> Also, do you think this will be primarily useful for partitioning devices that
> >> expose multiple physical functions? Or do you see a use case for SR-IOV with
> >> virtual functions as well. The pyhs_port attribute provides a common
> >> interface for both cases which is good I suppose in the VF case however the
> >> host can already learn this. I gather from your original post here that you are
> >> aware of all this.
> >>
> >
> > John, I think it will be useful in the SRIOV scenario also when more
> than one VF from two NICs are assigned to the guest. phys_port would be
> helpful in choosing the correct slave interfaces when host details are
> not available.
> 
> OK. But I'm not sure why you would assign two VFs from the same NIC
> to a guest? This doesn't seem like a good configuration for failover
> because if one VF fails it seems likely both will fail. Maybe there
> are some benefits for load balancing? Or my assumption both VFs will
> fail is wrong.

I believe Narendra is trying to provide hints to the guest that would
allow it to avoid such broken bonding configurations.  But it is
certainly a good question why there would be two VFs assigned in the
first place.

I could imagine passing through two VFs for the same physical port that
have been assigned to different VLANs.  But then you wouldn't want to
bond two devices that are on different VLANs, whether or not they're
using the same port!

> Anyways it does seem useful in the partitioning case with multiple
> physical functions.

I was thinking it could also help to support the hybrid guest networking
mode.  In this mode, the guest gets a PV (e.g. virtio_net) device and a
VF bridged to the same physical port, and the VF can be removed before
the guest is migrated (and maybe reinserted if there's a VF available on
the new host) without a major disruption to the guest.  In that case the
guest *should* bond together the two net devices that have the same
physical port ID but different drivers.  This would require the physical
port ID to be propagated through macvtap/macvlan and virtio.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

  reply	other threads:[~2013-06-28 17:09 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-17 18:10 [PATCH net-next] net: Add phys_port identifier to struct net_device and export it to sysfs Narendra_K
2013-06-17 18:47 ` John Fastabend
2013-06-19 14:29   ` Narendra_K
2013-06-19 15:36     ` Ben Hutchings
2013-06-19 18:53       ` Narendra_K
2013-06-19 19:34         ` Ben Hutchings
2013-06-19 21:37           ` Praveen_Paladugu
2013-06-21 17:11           ` John Fastabend
2013-06-25 17:33             ` Narendra_K
2013-06-28 16:33               ` John Fastabend
2013-06-28 17:09                 ` Ben Hutchings [this message]
2013-07-02 14:40                   ` Narendra_K
2013-07-11 20:39 ` Jiri Pirko
2013-07-15 15:34   ` Narendra_K
2013-07-21  5:55     ` Or Gerlitz
2013-07-21  7:24       ` Jiri Pirko
2013-07-21 11:14         ` Or Gerlitz
2013-07-21 14:48           ` Ben Hutchings
2013-07-21 20:29             ` Or Gerlitz
2013-07-21 20:50               ` Ben Hutchings
2013-07-22 11:46             ` Narendra_K
2013-07-22 11:49               ` Jiri Pirko
2013-07-22 15:48                 ` 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=1372439353.1937.21.camel@bwh-desktop.uk.level5networks.com \
    --to=bhutchings@solarflare.com \
    --cc=Narendra_K@Dell.com \
    --cc=john.fastabend@gmail.com \
    --cc=john.r.fastabend@intel.com \
    --cc=netdev@vger.kernel.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).