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
> these variable MCA parameters for each BTL that support them.
> 2. We create fake MCA parameters that will never be used, but they
> 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_* ...
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:
host1 eth0=latency,bw eth1=latency,bw
host2 eth0=latency,bw eth1=latency,bw
Or perhaps you might like the INI-style format:
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