[openib-general] Problem is routing CM REQ was: Use a GRH when appropriate for unicast packets

[Sean Hefty]

>Hum, you mean to meet the LID validation rules of 9.6.1.5? That is a
>huge PITA..
>
>[IMHO, 9.6.1.5 C9-54 is a mistake, if there is a GRH then the LRH.SLID
> should not be validated against the QP context since it makes it
> extra hard for multipath routing and QoS to work...]

Yes - this gets messy.

>Here is one thought on how to do this:
>To meet this rule each side of the CM must take the SLID from
>the incoming LRH as the DLID for the connection. This SLID will be
>one of the SLIDs for the local router. The other side doesn't need to
>know what it is. The passive side will get the router SLID from the
>REQ and the active side gets it from the ACK.
>
>The passive side is easy, it just path record queries the DGID and
>requests the DLID == the incoming LRH.SLID.

This requires that the passive side be able to issue path record queries, but I
think that it could work for static routes.  A point was made to me that the
remote side could be a TCA without query capabilities.

There's still the issue of what value is carried in the remote port LID in the
CM REQ (12.7.21), and I haven't even gotten to APM yet...

>The nasty problem is with the active side - CMA will select a router
>lid it uses as the DLID and the router may select a different LID for
>it to use as the SLID when it processes the ACK. By C9-54 they have to
>be the same :< So the active side might have to do another path record
>query to move its DLID and SL to match the routers choosen
>SLID. Double suck :P

As long as the SA and local routers are in sync, we may be okay here without a
second path record query.

- Sean