On 03/02/2016 01:40 PM, Or Gerlitz wrote: > On Wed, Mar 2, 2016 at 6:50 PM, Doug Ledford <dledf...@redhat.com> wrote: > >> 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? > > The provisioning system need not be fully aware in all their > components this is IB here, there's PCI linkage that tells these are > VFs of this PF and they have to be used for these VMs.
If I understand you correctly, then I don't think I agree. From what I read, I gather you mean: libvirt can be used to control guests today, and you can list a PCI device as "managed" and specify a MAC address (which has libvirt assuming the device is an ethernet device). In that case, libvirt automatically detaches the device from the host (if attached), figures out if it's a PF or VF, sets the MAC address using either PF or VF MAC setting methods in ethtool, attaches the device to the guest, then starts the guest. And you're saying we should put the MAC->GUID transformation into this code for IB so that libvirt can be blissfully ignorant and people can tell libvirt it's an ethernet device with a MAC and libvirt will treat it as such and life will be grand. Except it won't. Along with setting the GUID, we also need to set the P_Keys allowed list (at least using the alias GUIDs method of mlx4 you do, so unless you add a patch to this series to switch mlx4 to this new method, that's a valid concern). And nothing in libvirt can do that as long libvirt thinks this is ethernet because libvirt doesn't control the vlans on a guest's ethernet device, the guest does. In that sense, IB and ethernet vary greatly. So, at *best*, the solution you are suggesting for existing setups is a partial solution that leaves things only half done. I don't see the justification to clutter up upstream code with a solution that isn't at least completely functional in its implementation. If the solution is only partial, then I would rather leave it out and tell people to upgrade their libvirt to know about IB devices. This is actually further backed up, in my mind, by the fact that you can have RoCE/iWARP Ethernet devices and regular Ethernet devices, and libvirt needs to be taught the concept of an RDMA capable device, whether Ethernet or IB, so that when trying to select a host for migration it can make sure that the migration target has the same capabilities as the hardware you are migrating from. So, to me, doing this right *requires* a libvirt upgrade, and there is no sense in this middle ground GUID from MAC hack that you are suggesting. >>> 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. > > We **are** doing things right with the new ndo. > > Using the small MAC->GUID addition, people could be using non-modified > (or almost non-modified) provisioning systems that assign SRIOV VMs > with a MACs --- just use these patches on their hosts and get DHCP > server supplying IP addresses based on the derived GUIDs (this is > supported today). > -- Doug Ledford <dledf...@redhat.com> GPG KeyID: 0E572FDD
signature.asc
Description: OpenPGP digital signature