Messages in this thread |  | | | From | Casey Leedom <> | | Subject | Re: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address | | Date | Wed, 21 Jul 2010 11:29:47 -0700 |
| |
| From: David Miller <davem@davemloft.net> | Date: Wednesday, July 21, 2010 10:32 am | | From: Stephen Hemminger <shemminger@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.
| 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
|  |