This will benefit to several components: BTL/PTL, PML, having a common set of functions will be really useful. I just have a request. If we specify something like "--mca btl self,mvapi" I think it can be useful to get them in the specified order. For some components (like the BTL) it doesn't make any difference as we will use their internal priorities to order them.For others we can use the order as an indication of the user kind priority.

 Thanks,
   george.

Jeff Squyres wrote:
Short version:
--------------

I'd like to have a single, top-level MCA param for each framework that controls the "include" and "exclude" behavior of components. Something like:

        mpirun --mca btl self,mvapi ...

would "include" self, mvapi (this actually already works for dynamic compiles). And:

        mpirun --mca btl !tcp

would "exclude" tcp. This would be for all frameworks, at the mca_base_components_open() level, not during framework-specific selection. Hence, excluded / not-included components wouldn't even be opened (i.e., faster startup and smaller memory footprint).

Longer version:
---------------

Long, long ago, before Tim knew that I put in the <framework> MCA params into mca_base_components_open(), he added btl_base_include and btl_base_exclude to handle this kind of thing. I think that this should be handled at the MCA level itself -- there should be no need to have this kind of exclusion and inclusion at each framework.

More specifically, the frameworks can call mca_base_components_open() just as they do now, and if the MCA parameter for that framework was specified, mca_base_components_open() will obey it and pass back a customized list of components back to the caller. The btl_base_[include|exclude] parameters (and others similar to it) can then be removed.

Given that I already am on the hook to fix the static compile issue for 1.0, adding this functionality would be pretty trivial. Therefore, I'd like to do it for 1.0. It would also give us a nice, uniform way of including components across all frameworks.

It's also shorter to type on the command line.  :-)

Comments?


Reply via email to