Dasa, On 4/19/2017 12:54 PM, Chandramouli, Dasaratharaman wrote: > > Hal, > > On 4/19/2017 7:52 AM, Hal Rosenstock wrote: >> On 4/17/2017 4:56 PM, Dasaratharaman Chandramouli wrote: >>> When the bit 26 of capmask2 field in OPA classport info >>> query is set, SA will query for OPA path records instead >>> of querying for IB path records. >> >> If/when additional SA query types are supported for OPA, will each >> additional SA query type have separate CapMask2 bit or will they be >> combined into 1 ? For example, would SA MCMemberRecord be different for >> OPA (perhaps 32 bit MLID) and if so, would support be indicated by >> different capability bit or same one ? Is that the only other one ? > > There are no plans to provide a separate capmask2 bit for each of the > other queries. Glad to hear this. >> >> Currently, IB SA is using up through bit 13 and new features continue to >> be added (at least one more coming soon). There is some chance for >> feature collision if OPA would care about supporting such new IB feature >> if and when OPA and IB bitmasks meet with IB incrementing from bit 13 >> and OPA decrementing from bit 26. I wouldn't expect that to happen for a >> while but it would be best to anticipate this if it is of any concern to >> OPA. > > I see your concern. The capmask2 bits for OPA is not intended to be in > sync with IB. If, for instance, we have a new IB feature that is exposed > by Bit n of capmask, two things are possible. 1) OPA might not support > the same feature. If the class port info query that is 'cached' by the > SA is of type OPA, it implicitly means that the feature is not > supported. This patch series adds a function > "ib_sa_sendonly_fullmem_support" that is a good example of that case. > When a caller calls this function and if the class port info is of type > OPA, we just return 'false' implying that OPA doesn't possess > sendonly_fullmember suppprt. 2) OPA might support the feature. In this > case, OPA class port info will expose the feature in the capmask2 field > bit not necessarily in the same bit n. SA should be able to handle these > differences. Yes, those are the choices available. -- Hal >> -- Hal >> > > Thanks, > Dasa > -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
