[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