[ofa-general] Re: [PATCH 2/3] Add combined routing support to libibnetdisc

[Ira Weiny]

On Thu, 7 May 2009 09:56:38 -0400
Hal Rosenstock <hal.rosenstock at gmail.com> wrote:

> Ira,
> 
> On Wed, May 6, 2009 at 12:33 PM, Ira Weiny <weiny2 at llnl.gov> wrote:
> > On Wed, 6 May 2009 13:07:44 +0300
> > Sasha Khapyorsky <sashak at 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?
Ira