On 3/30/2015 8:16 PM, Jason Gunthorpe wrote:
But, it doesn't really make sense to use eth_random_addr (which doesn't have a special OUI) and not randomize every bit.get_random_bytes(&guid, sizeof(guid)); guid &= ~(1ULL << 56); guid |= 1ULL << 57;
OK, we can do that, sure.
I also don't think the kernel should be generating random GUIDs. Either the SA should be consulted to do this, or the management stack should generate a cloud wide unique number.
There **is** an option to consult with the SM controlled by the sm_guid_assign module param of mlx4_ib. When this mode is in action, the randomized guid would be overridden by the one assigned by the SA.
In real life environments, people will use the "host assigned" option (sm_guid_assign = false) where the virtualization systems generate a unique guid to be used by the VF/VM and provision it through mlx4_ib to be provided to VF when the bindin.
The only place where the random value will be used, is for OOTB experience for staging purposes and such, when one wants to have working system with zero-touch. The practice of generating locally random address for non-provisioned VF is also used by the pretty much the whole set of Ethernet VF drivers (ixgbe_vf, i40e_vf, mlx4 VF code, etc). This is low cost solution for point cases which need that.
Or. -- 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
