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

[Hal Rosenstock]

On Thu, May 7, 2009 at 11:58 AM, Ira Weiny <weiny2 at llnl.gov> wrote:
> 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?

Yes, this makes sense. Thanks for clarifying.

-- Hal

> Ira
>
>