[ofa-general] SubnAdmGet (6777)

[Hal Rosenstock]

On Mon, Jun 1, 2009 at 5:36 PM, Hal Rosenstock <hal.rosenstock at gmail.com> wrote:
> On Mon, Jun 1, 2009 at 4:27 PM, Sean Hefty <sean.hefty at 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
>