Re: [PATCH 19/25] mlx4: Randomizing mac addresses for slaves

[Roland Dreier <rdreier-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>]

 > > 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html