On Jun 13, 2007, at 12:03 PM, George Bosilca wrote:
I think the "hidden" MCA parameters are a different issue; they were
created for a different purpose (users are not supposed to see/set
them). These variable parameters would be intended to be used by the
users, but they would have no way of finding out a) that they exist,
and b) what they are. That's why I think that the MCA parameters may
not be the right mechanism for this kind of information.
I see 2 possible solutions:
1. we update our documentation in such a way that it will clearly
describe
these variable MCA parameters for each BTL that support them.
2. We create fake MCA parameters that will never be used, but they
will
show up in the ompi_info output so the user will know they exist.
For TCP
they can be btl_tcp_latency_* and btl_tcp_bandwidth_* ...
Or:
3. Use a file to convey this information, because it's better suited
to what we're trying to do (vs. MCA parameters).
Seriously, why is a file a bad thing? The file can list interfaces
by hostname. For example, if you have a heterogeneous setup, what's
to say that having btl_tcp_bandwidth_eth0 is not the same across all
your hosts? That is -- the MCA parameters you're providing are not
sufficient for a true heterogeneous environment, anyway.
Here's an example file format off the top of my head:
btl-tcp-if.txt:
host1 eth0=latency,bw eth1=latency,bw
host2 eth0=latency,bw eth1=latency,bw
Or perhaps you might like the INI-style format:
btl-tcp-if.ini:
[host1]
latency_eth0 = x1
bandwidth_eth0 = y1
latency_eth1 = x2
bandwidth_eth1 = y2
...or pick any other format/variation on the above.
In short: the data you're trying to provide is really (at least) a 2D
data set (hosts * interfaces). It's just not suitable for MCA
parameters.
--
Jeff Squyres
Cisco Systems
