On Wed, Aug 5, 2009 at 1:07 PM, Hal Rosenstock <[email protected]>wrote:
> > > On Wed, Aug 5, 2009 at 12:31 PM, Sasha Khapyorsky <[email protected]>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 >> > >
_______________________________________________ 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
