> >>>
> >>> diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h index
> >>> 3ab4033..2614233 100644
> >>> --- a/include/rdma/ib_verbs.h
> >>> +++ b/include/rdma/ib_verbs.h
> >>> @@ -128,6 +128,10 @@ enum ib_device_cap_flags {
> >>> IB_DEVICE_ON_DEMAND_PAGING = (1<<31),
> >>> };
> >>>
> >>> +enum ib_device_cap_flags2 {
> >>> + IB_DEVICE_OPA_MAD_SUPPORT = 1
> >>> +};
> >>> +
> >>> enum ib_signature_prot_cap {
> >>> IB_PROT_T10DIF_TYPE_1 = 1,
> >>> IB_PROT_T10DIF_TYPE_2 = 1 << 1,
> >>> @@ -210,6 +214,7 @@ struct ib_device_attr {
> >>> int sig_prot_cap;
> >>> int sig_guard_cap;
> >>> struct ib_odp_caps odp_caps;
> >>> + u64 device_cap_flags2;
> >>> u32 max_mad_size;
> >>> };
> >>>
> >>
> >> Why is OPA support determined via a device capability flag ? What are
> >> the tradeoffs for doing it this way versus the other choices that
> >> have been used in the past for other RDMA technologies like RoCE, iWARP,
> usNIC, ... ?
> >
> > None of those technologies use the MAD stack for Subnet Management.
> Other MAD support is very limited (ie IB compatible PMA queries on the local
> port only).
> >
> > Do you have a suggestion for alternatives?
>
> The desire to leverage the IB MAD infrastructure for OPA is understood but the
> current approach represents OPA as a device capability which does not seem
> appropriate because OPA is clearly a different type of RDMA technology than
> IB.
>
While it is a different type of technology, standard verbs[*] remains 100%
compatible. Unlike other verbs technologies user space software does not need
any knowledge that the underlying device is not IB. For example, PR (and SA)
queries, CM, rdmacm, and verbs calls themselves are all 100% IB compatible.
Therefore, to address your initial question regarding tradeoffs I believe this
method is the least invasive to the code as well as removing any potential
performance penalties to core verbs.
Ira
[*] We don't support some of the extensions particularly those which have been
most recently introduced. And we would like to make our own extensions in the
form of higher MTU availability, but the patch is not yet ready to be submitted
upstream.
--
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
