On 16:16 Thu 14 Jun , Yevgeny Kliteynik wrote: > Hi Sasha, > > Yevgeny Kliteynik wrote: > > Sasha Khapyorsky wrote: > >> Hi Yevgeny, > >> > >> On 11:19 Thu 14 Jun , Yevgeny Kliteynik wrote: > >>> The following three patches are adding root and compute node guid files > >>> options for fat-tree routing, > >> > >> Is there any reason to not share root guids file option with up/down? > > There are two new options for fat-tree: roots and compute nodes (CN). > > These two will be very "tightly coupled" and would have more implication > > on the routing than in case of up/dn roots. For instance, having root > > file but not CN file means that the topology doesn't have to be pure > > fat-tree, > > but all the CAs are considered CNs and have to be on the same level of the > > tree. > > And there is similar implication of all the combinations of these two > > options. > > Because of this coupling I wanted to differentiate these two options from > > the up/dn roots. > > Thoughts? > >> Also the way how root guids are handled (in both up/down and ftree) > >> doesn't look very optimal - guids are loaded to dynamic list, the list > >> is converted to map, this map is matched and root nodes are marked as > >> roots. Isn't it would be easy just to mark root nodes during file parsing? > > The only thing you can save here is converting list to map: > > You have to parse the guids file anyway, and you have to build all the > > fat-tree data structures anyway. So if you parse the file and fill the > > map right away instead of filling the list first, you will save the > > list2map conversion. > > But then up/dn and fat-tree can't use the same function to parse the guid > > file, > > and since the list2map conversion is not a big deal (we're talking about > > list > of roots, which is couple of hundreds of guids at max), I prefer to > > leave it and not to use separate parsing functions for up/dn and fat-tree. > > Actually, I can do something else here: > - parse guid file into list > - populate fat-tree switches and CAs > - scan guid list, and for each guid mark the matching node in the fat-tree > maps > > Sounds OK?
Yes, much better. Also there could be something like: - populate fat-tree switches and CAs - parse guid file, and for each guid mark the matching node (with custom callback) But with your proposition it is not needed to touch the parser (and up/down :)). 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
