On Tue, Jun 6, 2017 at 7:33 PM, Jason Gunthorpe <jgunthorpe@xxxxxxxxxxxxxxxxxxxx> wrote: > 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. > We reviewed your suggestion in deeper details and agree with your suggested semantics to allow user to create a QP with user defined wire QPN, without mandating association of an overlay with underlay QP. This will allow each vendor to implement this feature according to his HW capabilities. Thus the new attribute we will add to ib_create_qp will be 'source_qpn' and matching flag. Obviously this will require root privileges from user application, and thus in v2 we will extend the existing CAP_NET_RAW check on creation of this kind of QP with source QPN, as done in RAW_PACKET QP. Alex -- 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
