>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 _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
