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

[Sasha Khapyorsky]

On 15:36 Thu 14 Jun     , 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?

I still not have strong option about two options against common one.
Hypothetically if in some days we will implement routing engine chains
(so failed algo will fallback to next in chain and not just to default)
separate options could be useful.

> > 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:

I don't think the root guids map is needed - you can just set is_root
field for sw nodes by guid(s) specified in the file, since you already
have sw by guid 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.

You can pass custom callback to common parser.

>  BTW, since we're on this subject, how about removing the list2array 
>  conversion
>  in the same place in up/dn routing?

Sure, similar junk should be cleaned up in up/down too (and my original
complain was about both root guids users).

Sasha