On Thu, 7 May 2009 09:56:38 -0400 Hal Rosenstock <[email protected]> wrote:
> Ira, > > On Wed, May 6, 2009 at 12:33 PM, Ira Weiny <[email protected]> wrote: > > On Wed, 6 May 2009 13:07:44 +0300 > > Sasha Khapyorsky <[email protected]> wrote: > > [snip] > >> > >> And wouldn't it be better instead of resolving selfport on each > >> extend_path() call to keep it already resolved somewhere in fabric > >> structure? > > > > This will only happen 1 time for each fabric being scan'ed because the path > > is > > reused... > > > > Oh wait a minute, I just reviewed the code... For the current use case the > > path is reused since I am only scanning 1 node. However, in the general > > case > > this is not true. Sorry about that. A new patch is below. > > Does combined routing always fall back on failure to using directed routing ? No, not automatically in the library. > > Also, would you summarize the use cases for combined routing in ibnetdiscover > ? > ibnetdiscover does not use this feature. It does a "full scan" which results in only DR routing. iblinkinfo and ibqueryerrors have the ability to request output for a single node. The library was written to be able to scan from a given portid and a number of hops around that node. However, at first this only supported a DR path in the portid. If the user specified something like GUID iblinkinfo would scan the entire fabric and search the data which came back for that node. Of course the problem with is that on a large fabric it could take 8 seconds to come back with a single node of data. If the SM/SA is up and running I decided it would be better to query for the LID of that node and start the scan from there. That is what this patch adds. iblinkinfo and ibqueryerrors will call ibnd_discover_fabric with the "from" == to the portid resolved from the SA and "hops" == 1. If resolving the GUID or the limited scan fails ibqueryerrors and iblinkinfo then call the library again for a full fabric scan ("from" == NULL) and then search for the node in the fabric data returned. So that is the use case for doing this in the library. But once again ibnetdiscover does not use this. The other use case I could think of is doing a more extensive scan of multiple hops around a single node. I have not implemented this yet but in my early testing it worked just fine starting with a DR path. I believe this will still work with combined routing. Make sense? Ira _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
