On Tue, Jun 06, 2017 at 06:49:52PM +0300, Alex Rosenbaum wrote: > IPoIB is a tunneled protocol. The underlay part, a UD QP, has a set of > properties that define its L2-L4 characteristics. In this suggestion we > wanted to make sure the overlay will use the same QP so that there are > no mismatches between the IB layer properties. An example for such a > mistake can be if the overlay sets a PKey which is different than the > IPoIB UD QP. A mistake example on the receive flow; when setting > multiple ingress steering on using multiple different PKey's into a > single user space UD QP. That seems like a strange thing to worry about, any user of this already has to closely track all of the IB parameters as they are required to issue path records. So this underlay/overlay complexity really doesn't do much for safety/usability, IMHO - it just introduces more complexity and more failure modes. > Naming it "source_qpn" instead of associated, as you suggest, sound > more appropriate. Simpler, certainly if you completely eliminate the notion of a linkage to another QP. This is just creating a TX QP with a specified QPN that can overlap an existing bidir QP's QPN. This could then also be potentially used for applications that desire a fixed QPN. > As noted in previous email, the overlay QP can work properly only when > the underlay QP is not in RTR or RTS. Meaning no egress or ingress > traffic will happen once underlay is not in these states. This is Yuk, a hidden variable that causes undetectable failure is gross. 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
