>
> > 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
