Re: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address

[Casey Leedom]

| From: David Miller <davem@xxxxxxxxxxxxx>
| Date: Wednesday, July 21, 2010 10:32 am
| 
| From: Stephen Hemminger <shemminger@xxxxxxxxxx>
| 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.

| One idea I've proposed in other discussions about this is that if the
| address is not persistent (either via the MAC address bit or the sysfs
| value we're thinking of providing here) we use the device's geographic
| location ("device path") as the key for udev stuff.

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

Casey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/