On Wed, May 27, 2015 at 01:53:11PM -0400, Doug Ledford wrote: > > This basic idea is exactly why I think we should stick with the 20 > > byte LLADDR for ILFA_VF_MAC. It gives a route for the PF to tell the > > VF what QPN to use for IPoIB (if we ever see HW support to implement that) > > > > If we use 8 bytes then that route is closed off forever. > > And that's exactly as it should be. If we allow setting all 20 bytes > via the VF_MAC calls, then we violate the "guests should behave like > they are on bare metal as much as possible" rule. As a host, we get a > GUID and if we want to control the QPNs for IPoIB (and indeed if we > want
No, that doesn't really work. The PF's QPN pool is shared between all VF guests. The VF HCA does a call to the PF driver to get a free QPN to use. The VM cannot unilaterally select a QPN without global coordination. In other words, if a QPN is to be forced for IPoIB then it must come from the PF, which must get it from the orchestration software, which must globally coordinate to ensure the QPN is available on every PF the VM may want to run on. Similar to how the MAC must be globally unique. Will this ever be done? Probably not. But if it was, this interface would be the sanest way to go. Anyhow - as far as I'm concerned, fixing the IFLA_VF_MAC to have a proper length nullifies my concern. If we really needed we can switch to a 20 byte format with good compatability options in the future once we have a proper length. Jason -- 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
