[ofa-general] PATCH [0/3] osm: adding root and compute node guid files options for fat-tree

[Sasha Khapyorsky]

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