Sasha Khapyorsky wrote:
On 16:57 Fri 15 Jun , Hal Rosenstock wrote:
On Fri, 2007-06-15 at 16:59, Sasha Khapyorsky wrote:
On 16:39 Fri 15 Jun , Hal Rosenstock wrote:
On Thu, 2007-06-14 at 09:45, Sasha Khapyorsky wrote:
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.
Me neither.
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.
So is this a(nother) reason to keep the roots separate or would that be
dealt with when the routing fallback strategy changes ?
It is yet hypothetical. Currently I don't see a strong practical reasons
to have two separate root guids file options for up/down and fat-tree,
but guess this is minor and not showstopper.
Wouldn't a current practical reason be switching between up/down and fat
tree and they each have different roots ? Is that a real scenario ?
Sure (but guess in many cases selected roots will be same for both
algos).
I think that selected roots will always be same for both algos.
I can't think of any topology that will require different set of roots
for two algorithms that see the fabric as tree with routes going up and
then down.
I think this scenario will be handled well with single shared
option, like:
opensm -R ftree --roots-file ftree-roots-file
, and
opensm -R updn --roots-file updn-roots-file
I agree with this.
I will rework the patch and replace the updn_guid_file with root_guid_file,
and add cn_guid_file.
This also means that the OSM command line options -a or --add_guid_file
will be replaced with -O or --root_guid_file, and we will have additional
options for CN file: -C or --cn_guid_file
Sounds OK?
-- Yevgeny
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