On Thu, May 21, 2015 at 7:40 PM, Doug Ledford <[email protected]> wrote:
> The MAC/GUID mapping isn't the only thing that has to be faked here Exactly nothing is faked here, Virtualization systems such as open-stack provision unique 48 bit mac values to VMs, and it's perfectly legitimate and viable to derive 64 bit guid value from that mac. > Why are we suggesting to make this work with unmodified software? Why > aren't we doing this right and adding a new ndo entry point for the GUID? Because rome wasn't built in a day and nor will be the support for IB in today's/tomorrow's virtualization systems, e.g if you follow on this layering [1] Open-Stack / ODL controller [2] Open-Stack neutron / ODL agent [3] libvirt [4] user/kernel netlink API [5] kernel ndo API [6] ipoib [7] kernel verbs API [8] PF IB driver with the approach presented here, we only simply (yeah, simplicity could turn to be critical criteria in engineering) to few kernel only patches that deal with layers 6-8 and we are ready for all sorts of bring-ups, testing and even production! For reasons which I don't really see the practical / real life use case where there's a must to get them to work (but I will happy to hear on) one can go & change the world, namely patch layers 5 ---> 1 too and deal with all sort of dependencies for setting up a system. But guess what, this can be perfectly done in parallel with this small change. > you would also have to fake the vlan/pkey mapping. This just > seems the wrong thing to do. Repeating the above argument --- virt systems provision 12bit vlan-id to be set for VM traffic, which can be nicely map to 16 bit IB pkey doing the same job. I understand that you have sort of desire to see IB ala the full spec going into libvirt and from there up to the whole virtualization management space, but this doesn't need as an argument to not enable doing thing in the right direction. The upstream kernel supports SRIOV for IB over mlx4 for 3 years now, but this can't work with libvirt as is. Using these patches can make the thing. Couple of months ago, we both attended a call with the libvirt developers / maintainers from red-hat and they really liked this staged approach. 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
