> > Maybe the solution is to make the protocol selection explicit > > throughout the APIs and associate it with a QP, rather than > > attempting to list all transport protocols that a port can support. > > AH's are linked to a PD, not a QP.. But protocols are associated with QPs. I'm not sure *why* an AH is linked to a PD. Conceptually the association seems unnecessary. > If we had to do it again, a PD centric approach would be more > sensible: > > // Create a PD on 'port' using ah format 'protocol' > pd = ibv_pd_create(port, enum ah_type protocol); > > // Enable APM or resource sharing on the PD across two ports > ibv_pd_add_port(pd, alt_port); > > And get rid of the multi-port ib_device concept entirely. I think no matter what option is chosen, some limitation may end up being placed on how a device is used that may not map to hardware limits. I'm personally fine with that, but we need to define the right level of abstraction (and pick the right terms to describe them). -- 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
