Prev: wm8960: fix compile error
Next: sysfs: add entry to indicate network interfaces with random MAC address
From: David Miller on 21 Jul 2010 14:40
From: Casey Leedom <leedom(a)chelsio.com>
Date: Wed, 21 Jul 2010 11:29:47 -0700

> Another option might be to have a new Net Device Operations call to ask the
> adapter for a Unique Key. This could be formed for most devices via a tuple of
> the {PCI Vendor ID, PCI Device ID, Adapter Serial Number, Port Number, [and if
> applicable] Adapter Function ID}. Of course this could be a fairly long string
> ... :-)

If a unique key were available, it could be used to generate a persistent
MAC address.

And this sort of means that these drivers could use bits of the
device's geographic ID the construct persistent MAC addresses, but
only if done in a MAC namespace that could be guarenteed unique on the
local system.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: David Miller on 21 Jul 2010 14:50
From: "Rose, Gregory V" <gregory.v.rose(a)intel.com>
Date: Wed, 21 Jul 2010 11:43:19 -0700

> 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.

If the VM itself is the "physical entity" of the system, the logical
conclusion I come to is that some kind of key should be obtained
through the VM to uniquely give the device a persistent MAC.

You could do things like have the PF controller use the root filesystem
ID label to construct the VF's MAC address, or something like that.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Rose, Gregory V on 21 Jul 2010 14:50
>-----Original Message-----
>From: Casey Leedom [mailto:leedom(a)chelsio.com]
>Sent: Wednesday, July 21, 2010 11:30 AM
>To: David Miller
>Cc: shemminger(a)vyatta.com; andy(a)greyhouse.net; harald(a)redhat.com;
>bhutchings(a)solarflare.com; sassmann(a)redhat.com; netdev(a)vger.kernel.org;
>linux-kernel(a)vger.kernel.org; gospo(a)redhat.com; Rose, Gregory V; Duyck,
>Alexander H
>Subject: Re: [PATCH net-next] sysfs: add entry to indicate network
>interfaces with random MAC address
>
>| From: David Miller <davem(a)davemloft.net>
>| Date: Wednesday, July 21, 2010 10:32 am
>|
>| From: Stephen Hemminger <shemminger(a)vyatta.com>
>| Date: Wed, 21 Jul 2010 10:28:16 -0700
>|
>| > IMHO no local assigned address should be used by udev. The cxgb4
>driver
>| > should be using random value.
>| >
>| > Does anyone have an example of locally assigned address that has
>| > persistence so that udev could use it.
>|
>| The cxgb4 vf addresses are not random because they are fetched from
>the
>| card's NVRAM/EEPROM/firmware/whatever and thus are persistent.
>|
>| We definitely want udev to use persistent rules for them.
>|
>| This whole issue only exists because of the Intel VF case, where it
>| lacks persistent addresses but somehow we want to assign persistent
>| names to it's VF interfaces.
>
> Yes, we _explicitly_ wanted to have persistent MAC Addresses for our
>PCI-E SR-
>IOV Virtual Functions for a whole raft of reasons. The two most
>important were:
>
> 1. Linux' model for persistent device naming today seems to be
> oriented around persistent network device addresses.
>
> 2. Lots of data centers use MAC addresses for things like DHCP/BOOTP,
> security/filtering, etc.
>
>Our design goal was to look as much like a normal Ethernet MAC as
>possible in
>order to reduce the need for software/behavior changes.

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.

- Greg

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: David Miller on 21 Jul 2010 15:00
From: David Miller <davem(a)davemloft.net>
Date: Wed, 21 Jul 2010 11:48:51 -0700 (PDT)

> You could do things like have the PF controller use the root filesystem
> ID label to construct the VF's MAC address, or something like that.

And here I of course mean the root filesystem of the guest the VF will
be given to.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Rose, Gregory V on 21 Jul 2010 15:10
>-----Original Message-----
>From: David Miller [mailto:davem(a)davemloft.net]
>Sent: Wednesday, July 21, 2010 11:50 AM
>To: Rose, Gregory V
>Cc: leedom(a)chelsio.com; shemminger(a)vyatta.com; andy(a)greyhouse.net;
>harald(a)redhat.com; bhutchings(a)solarflare.com; sassmann(a)redhat.com;
>netdev(a)vger.kernel.org; linux-kernel(a)vger.kernel.org; gospo(a)redhat.com;
>Duyck, Alexander H
>Subject: Re: [PATCH net-next] sysfs: add entry to indicate network
>interfaces with random MAC address
>
>From: David Miller <davem(a)davemloft.net>
>Date: Wed, 21 Jul 2010 11:48:51 -0700 (PDT)
>
>> You could do things like have the PF controller use the root
>filesystem
>> ID label to construct the VF's MAC address, or something like that.
>
>And here I of course mean the root filesystem of the guest the VF will
>be given to.

I suppose you could do that but then the VM is going to have to be allowed to set its own MAC address. There is a lot of opposition and concern about allowing VMs to set their own MAC address.

Then there's also support in the kernel now for assigning VF MAC and VLAN via the iproute2 package "ip link" commands. The administrative SW that controls VMs should be assigning MAC addresses to VFs as needed. When the VF is de-assigned from the guest because the VM is migrating then the administrative SW can assign another VF to the VM at the migration target machine and assign the same MAC address then. This way it is all done administratively from the (supposedly) secure host VMM domain and we're not allowing VMs to set their own MAC address.

Ultimately I think I agree that some sort of approach such as you and others have been suggesting should be taken. I'm agnostic about which one because my view of how things should work is a bit different. But if the community thinks that finding some way to set a persistent MAC address for a VF is useful then I'd more than happy to make sure our drivers support that also.

As soon as it is decided what that is of course.

;-)

- Greg

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: wm8960: fix compile error
Next: sysfs: add entry to indicate network interfaces with random MAC address