Hal Rosenstock wrote: > On Wed, Jun 3, 2009 at 7:01 AM, Eli Dorfman (Voltaire) > <dorfman....@gmail.com> wrote: >> Hal Rosenstock wrote: >>> 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. >>> >> This may happen when pr_rcv_get_port_pair_paths() is called several times. >> The only case i see is pr_rcv_process_world() that means the request is >> without or wrong >> src and dest port or component mask for SGID and DGID is 0. > > Should the non standard process world only return 1 attribute for get > r.t. too many records status ?
SubnAdmGet should return only 1 record. This should be fixed for the case of SGID and/or DGID wildcarded. I submitted a patch with this fix to the list. Eli _______________________________________________ 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
