On Mon, Jun 1, 2009 at 5:36 PM, Hal Rosenstock <hal.rosenst...@gmail.com> wrote: > On Mon, Jun 1, 2009 at 4:27 PM, Sean Hefty <sean.he...@intel.com> 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.
I sit corrected :-) Your interpretation of the spec is correct. Also, in looking at OpenSM, the intent is as you indicate: it does try to only return 1 attibute for get PR. If when returning the response, there is more than 1 attribute in the list, it returns the too many records error. There must be some code path I don't see right now which is doing this. It would be useful to know the details of the query (get request) causing this. -- Hal > -- Hal > >> - 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
