On Wed, Jun 13, 2007 at 09:43:03PM -0400, Jeff Squyres wrote:
> On Jun 13, 2007, at 1:48 PM, Gleb Natapov wrote:
> >> 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.
> > I don't feel strongly one way or the other. The command line approach
> > was much easier to implement. Is it possible to have one parser for
> > all
> > BTLs or each one will have to implement different one?a
> Let's take a step back and see exactly what we *want*. Then we can
> talk about how to have an interface for it.
> 1. We want to be able to specify bandwidth/latency values for BTL
> modules (and possibly other kinds of modules).
Not only bandwidth/latency. Others too (like number of credits, all
btl_openib_ib_* parameters, btl_openib_use_eager_rdma, and many more,
basically everything that make sense for individual BTL).
Perhaps we can extend mca param stuff to handle parametrization on BTL
name. Like adding one more string parameter to
mca_base_param_lookup_int(int id, char *btl_name, int param_value);
Then if parameter "btl_openib_use_eager_rdma" is registered
mca_base_param_lookup_int(10, "mthca0", ¶m_value);
will automatically check for "btl_openib_use_eager_rdma_mthca0"
parameter. We can also extend mca_base_param_register_int() to get
additional boolean parameter to indicate that parameter is not component
global but can be specialized by individual BTL and ompi_info can mark
this kind of parameters.