[ofa-general] SubnAdmGet (6777)

[Hal Rosenstock]

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.

-- Hal

> - Sean