RE: [PATCH 16/20] IB/mad: Add Intel Omni-Path Architecture defines

Weiny, Ira
2015-01-19T22:50:38Z

>
> On Mon, Jan 19, 2015 at 07:57:22PM +0000, Weiny, Ira wrote:
>
> > Perhaps you can give us an example of where the current code would
> > work without modifications if the IBTA were to define any new base or
> > smp class version?
>
> I think the point here is that every check for OPA_MIN_CLASS_VERSION must
> also be combined with a check if the device in question is OPA or not.

This contradicts what you say below....

>
> I don't see a problem with sharing the kernel structs or MAD processing, as
> long as all OPA specific behavior is conditionalized on the device in question
> being OPA - it should never be conditionalized on the class version of the MAD.
>
> > commit a70a5af286b2985a0a95e9733d1e3166845a8be8
> > Author: Ira Weiny <ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > Date: Tue Sep 23 20:04:49 2014 -0400
> >
> > IB/mad: Add registration check for Intel Omni-Path Architecture
> > MADs
>
> For instance:
>
> + if (mad_reg_req->mgmt_class_version >=
> OPA_MIN_CLASS_VERSION
> + && !port_priv->qp_info[qpn].supports_jumbo_mads) {
>
> Is wrong because it means that no IB software can register for those MADs
> anymore, which is cross polluting the two architectures in the kernel.
>
> Presumably since supports_jumbo_mads is always true for OPA the above test
> is not required at all and this patch should be dropped.
>
> But I expect if we keep looking at uses of OPA_MIN_CLASS_VERSION we will
> see other cases where they need to be conditionalized?

That is the only use of OPA_MIN_CLASS_VERSION. I agree with your second assessment and I'll remove the patch from the next series.

Hal was this your assessment as well?

Ira