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

Yevgeny Kliteynik kliteyn at dev.mellanox.co.il
Thu Jun 14 07:00:06 PDT 2007


Sasha Khapyorsky wrote:
> 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 :)).

OK, I'll rewrite it as I've described it.
What about the rest of the patches?

-- Yevgeny


> Sasha
> 




More information about the general mailing list