On Wed, Jul 20, 2011 at 04:53:36PM -0700, Ira Weiny wrote: > > The ibtool version of this switches the starting LID with the > > connected switch in this case.. > > Given a LID (resolved from a PR query of a GUID) for a CA port, how > do you know the connected switch? Via sa query?
Yes, there is also a general question when and if various tools should use SMPs vs use the SA... > > Note, doing tricks like this with the DR path screws up the > > localPortNum value, so if you ever read Port/NodeInfo using a path > > that has been manipulated like this it needs a fixup step. > > Not sure I follow you. To be clear this patch alters the path like this: > > Given DR path 0,1,3,4, where 0,1,3,4 ends at a CA > > "retract" the path to 0,1,3 and query that node as well as 0,1,3,4. > Resolve the port linkage and return that "fabric" to the user. If you issue a NodeRecord SMP to DR path 0,1,3,4 you will get localPortNum of 1. If you then algorithmically want to construct a DR path of 0,1,3,4,1 to reach the device connected to the CA port your algorithm will adjust it to 0,1,3, but a NodeRecord SMP will not return a localPortNum of 3, which would be expected from the construction of the original path. It depends on how your other algorithms are using this feature, but, eg for a tracing application that wants to print each hop along the path, messing up the localPortNum during the adjustment is bad news. > Given a combined route DLID+path the CA is resolved and returned. > There is, as you say below, no way to resolve (via SMP queries) the > connected node without scanning the entire fabric and resolving the > connection. You trace through the LFT from the local end port to the target CA DLID and that gives you a path to the switch. > > Also, there is a bug, you can't DLID route to the local HCA and then > > use that as a source of a DR path, even though intuitively that should > > work. > > A bug in the code? In Linux or the HCA I think. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
