> > I think the mistake in the tree is either having different protocols > > map to the same QP type value, or not having a separate protocol > field > > provided as part of create QP. > > The QP type value specifies the API contract to the verbs consumer. I disagree. The primary API contract is determined by the device attributes and capabilities. The QP type isn't known or used until well after that. The QP type should only determine the behavior of QP related calls: create/modify/query qp, post_send, post_recv, and ib_wc data. And even with these, we risk making assumptions. For example, QP type is independent of memory registration, which affects the input to send/recv. An issue we've had is linking attributes with orthogonal APIs/behaviors. Some of these were fixed by adding the rdma_protocol_xxx() and rdma_cap_xxx() calls. We shouldn't have QP type carrying broad API implications. IMO, selecting the wire protocol seems ideal, so I still feel that introducing a new QP type is sensible in this case. Add documentation for which QP/AH attributes are valid for each QP type if that helps. QPs could be classified at a higher level to define a *general* API flow that's independent of the protocol. E.g. provide helper functions to mark a QP as either reliable/unreliable and connected/unconnected. That would provide a minimal list of what verbs should be supported, though details on which fields are used still end up device/protocol specific. - Sean
