> > enum ibv_qp_type {
> > IBV_QPT_RC = 2,
> > IBV_QPT_UC,
> > - IBV_QPT_UD
> > + IBV_QPT_UD,
> > + IBV_QPT_XRC_SEND,
> > + IBV_QPT_XRC_RECV
> > };
>
> Sean,
>
> The upstream kernel (below) uses already the values 5 and 6 for
> the IB RAW qp types
>
> > enum ib_qp_type {
> > IB_QPT_SMI,
> > IB_QPT_GSI,
> > IB_QPT_RC,
> > IB_QPT_UC,
> > IB_QPT_UD,
> > IB_QPT_RAW_IPV6,
> > IB_QPT_RAW_ETHERTYPE
> > };
>
>
> ofed (below) uses 5 for XRC, 6/7 for IB raw qp types
> and 8 for the new "eth packet qp", XRC and the packet QP
> are used from user space with code which is out...
> so if possible can we at least keep the packet qp type value
> unchanged, as for XRC its different API...
>
> > enum ib_qp_type {
> > IB_QPT_SMI,
> > IB_QPT_GSI,
> > IB_QPT_RC,
> > IB_QPT_UC,
> > IB_QPT_UD,
> > IB_QPT_XRC,
> > IB_QPT_RAW_IPV6,
> > IB_QPT_RAW_ETHERTYPE,
> > IB_QPT_RAW_PACKET
I don't know if user space can allocate raw qps, but to be safe, I'll add XRC
INI and TGT QP types after IB_QPT_RAW_ETHERTYPE (values 7 and 8) and adjust
ibverbs to make the mapping simple. What I was trying to suggest in my other
email is for OFA to do something like this going forward:
enum ib_qp_type {
upstream values... ,
IB_QPT_OFA_SPECIFIC = 2 << 24,
IB_QPT_OFA_XRC,
IB_QPT_OFA_RAW_PACKET
};
So, we don't end up with conflicting types, and OFA can treat OFA_XRC
differently if the accepted XRC patches end up being different. (Of course,
it's too late to fix OFA XRC this way, but maybe it's possible for OFA to
support existing apps with only a recompile?)
- Sean
--
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
