> > > Is QP type definition already exported to user space? > > QP Type could be a bad name, open to ideas I think the name "QP Type" is bad... I want to say "transport type" but I don't think that really communicates what we want here. > > > I see IBV_QPT_RC/UC/UD/RAW_PACKET/XRC_SEND/XRC_RECV, but not > GMP in verbs.h. > > GMP is a special case of UD. I think this is where QP Type (or "Transport type") are not equivalent to if a path needs to be reversible or not. To properly derive the reversibility requires more than the transport. There is nothing which precludes me from requesting a reversible path for any QP Type. This is really a "protocol" attribute and it seems that each protocol could potentially want a reversible Path Record independent of the QP or "Transport Type". > > > > > +/* Local Service ServiceID attribute */ struct > > > > +rdma_nla_ls_service_id { > > > > + __be64 service_id; > > > > +}; > > > > > > Do not expose BE to userspace, everything should be in cpu order. > > > > If we use cpu order, we need to do two conversions: from BE to cpu > > order in kernel and from cpu order to BE in user space. Struct > > ib_user_path_rec contains many __be32 fields. > > I don't see a problem with the extra conversion. Neither do I. All user space values should be in host order. Ira -- 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