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

[Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]

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.

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?

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html