On Thu, May 7, 2009 at 11:58 AM, Ira Weiny <wei...@llnl.gov> wrote: > On Thu, 7 May 2009 09:56:38 -0400 > Hal Rosenstock <hal.rosenst...@gmail.com> wrote: > >> Ira, >> >> On Wed, May 6, 2009 at 12:33 PM, Ira Weiny <wei...@llnl.gov> wrote: >> > On Wed, 6 May 2009 13:07:44 +0300 >> > Sasha Khapyorsky <sas...@voltaire.com> 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?
Yes, this makes sense. Thanks for clarifying. -- Hal > Ira > > _______________________________________________ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general