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.
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.
-- 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
