On Mon, Jun 1, 2009 at 4:27 PM, Sean Hefty <[email protected]> wrote: >>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.
Seems so. > The spec indicates that value in the request is ignored and NumbPath is 1, not > that NumbPath is completely ignored. For Get, it doesn't say that the matches are paired down to this number as it does for GetTable. > 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)'. SDP annex is not the primary source for this (chapter 15 is) and is inconsistent and no one caught this. > 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. when there's a subnet with multiple paths and the requests are not specific enough to use get. Seems like either the queries need to use RMPP, or the spec modified (if that's possible) and the SAs updated. -- Hal > - Sean _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
