> > igb uses the full output of random_ether_addr(). I'd be fine with > > that. However setting the OUI means you only get 24 bits of randomness > > which makes a collision a lot more likely. > > IIRC that was precisely why the OUI isn't used for the igb driver. > > Perhaps some infrastructure (by which I mean a random_mac() function) > is warranted so at least this discussion can be concentrated around that > rather than repeating it for each driver that needs random mac addresses.
What would be the difference between random_mac() and the existing random_ether_addr() function? If one chooses a random address with a given OUI, then with only 24 bits of randomness, the birthday paradox says it takes only a few thousand addresses to get a collision (easy to hit given even a modest-sized virtualization setup). With the 46 bits that random_ether_addr() gives it takes millions of addresses to be likely to get a collision, which is probably comfortable for most ethernets. So it seems that random_ether_addr() is exactly what we should be using for VFs -- the only alternative I see is for the manufacturer to allocate N extra ethernet addresses for a NIC that supports N virtual functions, and use those assigned addresses. But if the kernel is making up ethernet addresses then we better use all the bits we can. - R. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
