> > 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 <[email protected]> > > 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 -- 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
