Yevgeny Kliteynik wrote:
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
Sorry, -C is already taken. I'm running out of letters here... :)
Suggesting leaving 'a' for roots, and using 'u' for CNs:
-a or --root_guid_file
-u or --cn_guid_file
-- Yevgeny
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
_______________________________________________
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
