[ofa-general] Re: [PATCHv2] opensm: Parallelize (Stripe) LFT sets across switches

[Hal Rosenstock]

On Wed, Aug 5, 2009 at 1:07 PM, Hal Rosenstock <hal.rosenstock at gmail.com>wrote:

>
>
>  On Wed, Aug 5, 2009 at 12:31 PM, Sasha Khapyorsky <sashak at voltaire.com>wrote:
>
>> On 10:43 Wed 05 Aug     , Hal Rosenstock wrote:
>> >
>> > Should this be done as a separate step on the way to the LFT
>> parallelization
>> > across switches ?
>>
>> What do you mean by "separate step" (separate from what)?
>
>
> Separate patches: first to move the osm_ucast_mgr_set_fwd_table call up a
> level and a second one to the implement the LFT parallelization across
> switches underneath that.
>
>
>>
>>
>> I'm trying to replay the idea again: each routing engine calculates LFTs
>> and fill sw->new_lfts array accordingly, after all it calls a procedure
>> for sending switches' LFT blocks (and TOPs). So routing engine itself
>> should not care about how exactly LFT blocks update MADs submission is
>> actually implemented.
>>
>
>
> Yes, understood.
>

The one issue which gets in the way a bit here is the port order list (only
applicable to certain engines and not others). Due to this, there are two
places where the FT MAD pushing occurs. It'll be clearer when I submit the
patch for this.

One other thing I ran into (and related to the osm_ucast_file.c patch I sent
a little while ago is the significance of > 0 returns from build_fwd_tables.
Is there a reason that a routing engine would want to run its
build_fwd_tables and then run the default one ? That seems to be what it
does.

It might be useful to document the status returns from build_lid_matrices
and build_fwd_tables.

-- Hal


>
> -- Hal
>
>
>>
>> Sasha
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20090806/367ff747/attachment.html>