On Wed, 20 Jul 2011 16:34:51 -0700 Jason Gunthorpe <[email protected]> wrote:
> On Wed, Jul 20, 2011 at 04:16:55PM -0700, Ira Weiny wrote: > > > > The old algorithm would attempt to extend a DR path through the CA and fail. > > The new algorithm retracts the path properly. > > > > This does not work when combined routing is used with the CA as a starting > > point. :-( > > 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? > Having that general functionality > means you can easially write a traceroute routine with this common > code. Yes that would be nice. But again requires more sa queries. > > 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. 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. > > 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? Ira > > Jason -- Ira Weiny Math Programmer/Computer Scientist Lawrence Livermore National Lab 925-423-8008 [email protected] -- 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
