On Tue, Aug 29, 2017 at 11:20:51AM -0400, Doug Ledford wrote: > > rdma.fixup-mtrr.awk > > - Obsolete, supports ancient hardware, done in kernel now > > Yeah, this is droppable. It was needed back in the SDR days for qib > hardware. PR #199 deletes this file > > rdma.mlx4-setup.sh > > rdma.mlx4.conf > > rdma.mlx4.sys.modprobe > > - Mellanox says they now prefer it if the device's EEPROM is > > configured, instead of this approach. So this is old > > Right, but it still needs to stick around for now. Even though the > EEPROM approach is preferred, not all mlx4 level devices support it, > and given that mlx4 is still very much in use, we need to keep it. The modprobe approach is not compatible with hotplug. Instead, we really want this to run from a udev rule, but the mlx4 driver does not create a kobject from mlx_core, so there is nothing to trigger the rule on :| I guess a kernel patch will be needed here.. > > Maybe it should move > > to kernel-boot, but also unclear why we need it? doesn't > > libvirt do this nowadays? > > It needs to die. For a very long time libvirt has not been smart > enough to deal with the dual ports on mlx4 hardware. There has been > work upstream in libvirt to make this work. The scripts here are > useless for any guests that are open to migration as they preconfigure > the devices and then you attach the device to the guest more or less > unmanaged. Libvirt/qemu can never migrate the host because it doesn't > know how to set up the card on the new host the same way. It's my hope > that the rdma tool will be expanded to support the different SRIOV > configuration methods (mlx4 and mlx5 are totally different) > transparently. If/when that happens, it will be easy for libvirt to > standardize on that method and move this to "fully supported" status. > Right now, this support is just to allow people to statically configure > SRIOV for use, but I don't consider something that can't migrate guests > production ready IMO. Okay, lets leave that as redhat/, but I thought Mellanox sorted this all out with the ipoib netlink patches related to sriov? Sigh. > > rdma.udev-ipoib-naming.rules > > - This is a user example for udev rules.. > > Could go into kernel-boot > > Right. This is a totally generic udev consistent device naming > support. Done in PR #199 Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
