>Yes, RMPP is an overhead when the response is a single MAD but is this >significant ? Anyhow, how can the spec be changed in a way that >doesn't break existing implementations ?
But the implementations are assuming different things about SubnAdmGet. The SA is assuming that the query should fail if multiple records match. The client side software (ipoib and rdma_cm) assume that it will obtain a single record even if multiple paths are present. So, something needs to change. The spec indicates that value in the request is ignored and NumbPath is 1, not that NumbPath is completely ignored. Also see page 1242 in the SDP annex which reads: 'NumbPath could be 1 (in which case the SA query may use SubnAdmGet rather than SubnAdmGetTable)'. To me, this implies that SubnAdmGet should be treated equivalent as SubnAdmGetTable with NumbPath = 1. It just seems really odd to treat NumbPath differently for PR SubnAdmGet versus PR SubnAdmGetTable and MPR SubAdmGetMulti. Basically, this makes PR SubnAdmGet useless. - Sean _______________________________________________ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
