netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Shannon Nelson <shannon.nelson@oracle.com>
Cc: Jakub Kicinski <jakub.kicinski@netronome.com>,
	Hannes Frederic Sowa <hannes@redhat.com>,
	achiad shochat <achiad.mellanox@gmail.com>,
	Sridhar Samudrala <sridhar.samudrala@intel.com>,
	netdev <netdev@vger.kernel.org>,
	virtualization@lists.linux-foundation.org,
	Achiad <achiad@mellanox.com>,
	Peter Waskiewicz Jr <peter.waskiewicz.jr@intel.com>,
	"Singhai, Anjali" <anjali.singhai@intel.com>,
	Andy Gospodarek <gospo@broadcom.com>,
	Or Gerlitz <gerlitz.or@gmail.com>
Subject: Re: [RFC] virtio-net: help live migrate SR-IOV devices
Date: Sun, 3 Dec 2017 07:05:12 +0200	[thread overview]
Message-ID: <20171203065759-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <780cf854-83e1-b2a4-0f07-74372a972ca6@oracle.com>

On Fri, Dec 01, 2017 at 12:08:59PM -0800, Shannon Nelson wrote:
> On 11/30/2017 6:11 AM, Michael S. Tsirkin wrote:
> > On Thu, Nov 30, 2017 at 10:08:45AM +0200, achiad shochat wrote:
> > > Re. problem #2:
> > > Indeed the best way to address it seems to be to enslave the VF driver
> > > netdev under a persistent anchor netdev.
> > > And it's indeed desired to allow (but not enforce) PV netdev and VF
> > > netdev to work in conjunction.
> > > And it's indeed desired that this enslavement logic work out-of-the box.
> > > But in case of PV+VF some configurable policies must be in place (and
> > > they'd better be generic rather than differ per PV technology).
> > > For example - based on which characteristics should the PV+VF coupling
> > > be done? netvsc uses MAC address, but that might not always be the
> > > desire.
> > 
> > It's a policy but not guest userspace policy.
> > 
> > The hypervisor certainly knows.
> > 
> > Are you concerned that someone might want to create two devices with the
> > same MAC for an unrelated reason?  If so, hypervisor could easily set a
> > flag in the virtio device to say "this is a backup, use MAC to find
> > another device".
> 
> This is something I was going to suggest: a flag or other configuration on
> the virtio device to help control how this new feature is used.  I can
> imagine this might be useful to control from either the hypervisor side or
> the VM side.
> 
> The hypervisor might want to (1) disable it (force it off), (2) enable it
> for VM choice, or (3) force it on for the VM.  In case (2), the VM might be
> able to chose whether it wants to make use of the feature, or stick with the
> bonding solution.
> 
> Either way, the kernel is making a feature available, and the user (VM or
> hypervisor) is able to control it by selecting the feature based on the
> policy desired.
> 
> sln

I'm not sure what's the feature that is available here.

I saw this as a flag that says "this device shares backend with another
network device which can be found using MAC, and that backend should be
preferred".  kernel then forces configuration which uses that other
backend - as long as it exists.

However, please Cc virtio-dev mailing list if we are doing this since
this is a spec extension.

-- 
MST

  reply	other threads:[~2017-12-03  5:05 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20171128112722.00003716@intel.com>
2017-11-30  3:29 ` [RFC] virtio-net: help live migrate SR-IOV devices Jason Wang
2017-11-30  3:51   ` Jakub Kicinski
2017-11-30  4:10     ` Stephen Hemminger
2017-11-30  4:21       ` Jakub Kicinski
2017-11-30 13:54     ` Michael S. Tsirkin
2017-11-30 20:48       ` Jakub Kicinski
2017-12-01  5:13         ` Michael S. Tsirkin
2017-11-30  8:08   ` achiad shochat
2017-11-30 14:11     ` Michael S. Tsirkin
2017-12-01 20:08       ` Shannon Nelson
2017-12-03  5:05         ` Michael S. Tsirkin [this message]
2017-12-03  9:14           ` achiad shochat
2017-12-03 17:35             ` Stephen Hemminger
2017-12-04  9:51               ` achiad shochat
2017-12-04 16:30                 ` Alexander Duyck
2017-12-05  9:59                   ` achiad shochat
2017-12-05 19:20                     ` Michael S. Tsirkin
2017-12-05 21:52                       ` Jesse Brandeburg
2017-12-05 22:05                         ` Michael S. Tsirkin
2017-12-07  7:28                       ` achiad shochat
2017-12-07 16:45                         ` Alexander Duyck
2017-12-07 16:53                           ` Michael S. Tsirkin
2017-12-05 22:29                     ` Jakub Kicinski
2017-12-05 22:41                       ` Stephen Hemminger
2017-11-30 14:14   ` Michael S. Tsirkin

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=20171203065759-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=achiad.mellanox@gmail.com \
    --cc=achiad@mellanox.com \
    --cc=anjali.singhai@intel.com \
    --cc=gerlitz.or@gmail.com \
    --cc=gospo@broadcom.com \
    --cc=hannes@redhat.com \
    --cc=jakub.kicinski@netronome.com \
    --cc=netdev@vger.kernel.org \
    --cc=peter.waskiewicz.jr@intel.com \
    --cc=shannon.nelson@oracle.com \
    --cc=sridhar.samudrala@intel.com \
    --cc=virtualization@lists.linux-foundation.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).