netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Assmann <sassmann@redhat.com>
To: "Rose, Gregory V" <gregory.v.rose@intel.com>
Cc: Casey Leedom <leedom@chelsio.com>,
	David Miller <davem@davemloft.net>,
	"shemminger@vyatta.com" <shemminger@vyatta.com>,
	"andy@greyhouse.net" <andy@greyhouse.net>,
	"harald@redhat.com" <harald@redhat.com>,
	"bhutchings@solarflare.com" <bhutchings@solarflare.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"gospo@redhat.com" <gospo@redhat.com>,
	"Duyck, Alexander H" <alexander.h.duyck@intel.com>
Subject: Re: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address
Date: Thu, 22 Jul 2010 08:53:39 +0200	[thread overview]
Message-ID: <4C47EAF3.3080602@redhat.com> (raw)
In-Reply-To: <43F901BD926A4E43B106BF17856F0755F184620A@orsmsx508.amr.corp.intel.com>

On 21.07.2010 20:43, Rose, Gregory V wrote:
> I'm curious, what happens when the VM using the VF migrates to a new machine and has another VF assigned to with a different MAC address?
> 
> Intel's view of things is that we don't use persistent MAC addresses in our VFs because the MAC address belongs to the VM and when it migrates it's going to want to use another VF with the same MAC address.  If they're persistent I'm wondering how that can be done.
> 
> This discussion has come about because some folks want to use the VF in the Host VMM.  The original design goal for Intel was that VFs would be assigned to VMs and that VMM vendors would want to assign MAC addresses with their own assigned OUI's.

Using the VF in the host is a feature and I'm sure people will think of
ways to make good use of it. However the actual problem we've seen is a
more practical one. So to pass-through a VF to a VM the host has to be
aware that the VF exists. Therefore you usually have to enable the VF in
the host (i.e. specify the max_vfs parameter). The device will be
discovered by the system and because of the random MAC address udev
ignores the new device. With the additional information we provide with
our solution udev will be able to recognize the device by it's "device
path" and handle it properly (until you decide to pass it to a VM or
just be happy with it in the host).

Remember the issue that lead to the proposal of renaming VFs to vfeth?
That's exactly the problem we try to fix. Additional benefit of an
"address assignment type" as Ben likes to call it would be the handling
of MAC address stealing NICs.

  Stefan
--
Stefan Assmann         | Red Hat GmbH
Software Engineer      | Otto-Hahn-Strasse 20, 85609 Dornach
                       | HR: Amtsgericht Muenchen HRB 153243
                       | GF: Brendan Lane, Charlie Peters,
sassmann at redhat.com |     Michael Cunningham, Charles Cachera

  parent reply	other threads:[~2010-07-22  6:53 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-20 10:50 [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address Stefan Assmann
2010-07-20 11:20 ` Ben Hutchings
2010-07-20 11:47   ` Stefan Assmann
2010-07-20 11:58     ` Alex Badea
2010-07-20 12:17       ` Stefan Assmann
2010-07-20 20:18         ` David Miller
2010-07-21  8:10           ` Stefan Assmann
2010-07-21 13:54             ` Ben Hutchings
2010-07-22 12:50               ` [PATCH net-next] sysfs: add attribute to indicate hw address assignment type Stefan Assmann
2010-07-22 14:07                 ` Ben Hutchings
2010-07-22 14:47                   ` Stefan Assmann
2010-07-25  3:50                     ` David Miller
2010-07-20 12:07     ` [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address Ben Hutchings
2010-07-20 12:41       ` Stefan Assmann
2010-07-20 14:29         ` Ben Hutchings
2010-07-20 20:17           ` David Miller
2010-07-20 21:18             ` Stephen Hemminger
2010-07-20 21:20               ` David Miller
2010-07-21  6:26                 ` Harald Hoyer
2010-07-21  6:34                   ` David Miller
2010-07-21  6:47                     ` Harald Hoyer
2010-07-21 15:07                       ` Andy Gospodarek
2010-07-21 16:34                         ` Casey Leedom
2010-07-21 17:28                           ` Stephen Hemminger
2010-07-21 17:32                             ` David Miller
2010-07-21 18:29                               ` Casey Leedom
2010-07-21 18:39                                 ` David Miller
2010-07-21 19:25                                   ` Casey Leedom
2010-07-21 18:43                                 ` Rose, Gregory V
2010-07-21 18:48                                   ` David Miller
2010-07-21 18:50                                     ` David Miller
2010-07-21 19:02                                       ` Rose, Gregory V
2010-07-21 19:33                                         ` David Miller
2010-07-21 19:35                                           ` Rose, Gregory V
2010-07-22  7:12                                           ` Ian Campbell
2010-07-22  6:53                                   ` Stefan Assmann [this message]
2010-07-23  0:26                                     ` Casey Leedom
2010-07-23  8:08                                       ` Stefan Assmann
2010-07-23 16:35                                         ` Casey Leedom

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=4C47EAF3.3080602@redhat.com \
    --to=sassmann@redhat.com \
    --cc=alexander.h.duyck@intel.com \
    --cc=andy@greyhouse.net \
    --cc=bhutchings@solarflare.com \
    --cc=davem@davemloft.net \
    --cc=gospo@redhat.com \
    --cc=gregory.v.rose@intel.com \
    --cc=harald@redhat.com \
    --cc=leedom@chelsio.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@vyatta.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).