On 3/1/2016 4:08 PM, Or Gerlitz wrote:

On Tue, Mar 1, 2016 at 8:25 PM, Jason Gunthorpe
[off-list ref] wrote:

quoted

On Tue, Mar 01, 2016 at 07:49:51PM +0200, Eli Cohen wrote:

quoted

On Tue, Mar 01, 2016 at 10:37:51AM -0700, Jason Gunthorpe wrote:

quoted

quoted

+ 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.