Hal Rosenstock wrote: > On Mon, Jun 1, 2009 at 5:36 PM, Hal Rosenstock <[email protected]> > wrote: >> 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. > > 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. Eli _______________________________________________ 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
