On 3/1/2016 4:08 PM, Or Gerlitz wrote: > On Tue, Mar 1, 2016 at 8:25 PM, Jason Gunthorpe > <jgunthorpe@xxxxxxxxxxxxxxxxxxxx> wrote: >> On Tue, Mar 01, 2016 at 07:49:51PM +0200, Eli Cohen wrote: >>> On Tue, Mar 01, 2016 at 10:37:51AM -0700, Jason Gunthorpe wrote: >>>>> + return handle_infiniband_guid(dev, &ivt, IFLA_VF_IB_PORT_GUID); >>>> >>>> But is this emulation really necessary? It seems dangerous and >>>> continues the bad practice of assuming IFLA_VF_MAC is fixed to 6 bytes >>>> in size, and is not just LLADDR bytes. I'd rather see mac sets fail on >>>> IB. >>>> >>> struct ifla_vf_mac already defines mac as 32 bytes but the idea here >>> is that applications that configure six byte Ethernet MACs to VFs will >>> continue to work without any change. >> >> In my view it is incorrect for an application to try and set a 6 byte >> mac on an *infiniband* interface, the kernel should refuse to do it. > > As Eli wrote, there's a well defined way to extend MAC to GUID. With > that in hand, the idea here is to allow staged/evolved support for IB > Virtualization using un-touched provisioning systems which assign VMs > with 6-byte MACs Exactly *what* provisioning system tries to set the VF_MAC on an IPoIB interface and expects it to set the GUID of an underlying IB device? > along with the fully IB aware solution where the > upper level does provision IB GUIDs. There has never been upstream support for this MAC->GUID stuff you refer to. I'm not convinced we should add it now versus just doing things right, period.
Attachment:
signature.asc
Description: OpenPGP digital signature
