Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] RFC: shiny new variable subsystem
From: Jeff Squyres (jsquyres) (jsquyres_at_[hidden])
Date: 2013-02-01 08:19:31


Nathan and I have been talking about this for quite a while. Note that this is the first of several updates that we will have for the MCA param system -- we have a roadmap that can be easily described as two groups of things:

1. Changes that are intended for v1.7.x: everything to support MPI-3's MPI_T interface
2. Change that can wait until 1.9: long-standing MCA param feature requests and breaking backwards compatibility

Like Nathan said, we'll talk through this next Tuesday. He highlighted most of the important parts, but I wanted to explain one point a little further: as Nathan said, we took the opportunity to greenfield the MCA param API. Meaning: we designed a whole new OPAL MCA param API, taking into account all that we have learned from years of experience with the current MCA param API.

This is worth explaining a bit:

- The new API will be pushed to v1.7.
- But *the old API will also exist in v1.7* (as a thin shim compatibility layer to the new API)
- We will update all components and frameworks in both trunk and v1.7 to use the new API
- Any off-trunk development can still use the old API for the duration of the v1.7/v1.8 series
- After a while, *we will remove the old API/compatibility shim on the trunk/v1.9* (dates TBD)
*** Off-trunk development will therefore need to be updated for trunk/v1.9

The new MCA param API is cleaner, simpler, and provides for a lot of functionality that we don't currently have, like:

- un-overrideable system-level MCA params (as Nathan described)
- much shorter default ompi_info output (e.g., by default, only showing users the <some_single_digit_number> MCA params they really care about, not all 6 billion of them)
- ...and others

On Jan 31, 2013, at 8:22 PM, Nathan Hjelm <hjelmn_at_[hidden]> wrote:

> What: Introduce the MCA variable system. This system is meant as a replacement for the MCA parameter system. It offers a number of improvements over the old system including:
> - Cleaner, expandable API. Instead of providing multiple variable registration functions (reg_int, reg_int_name, reg_string, reg_string_name) there are only two (three when the framework system is introduced): mca_base_var_register() and mca_base_component_var_register().
> - Support for boolean variables.
> - Support for true/false values for integer and boolean variable. ex: setting OMPI_MCA_mca_component_show_load_errors=true will work the same as OMPI_MCA_mca_component_show_load_errors=1.
> - Support for integer enumerations. Example: create a integer variable foo with possible values 0:none, 1:error, 2: warning then any of OMPI_MCA_foo=none OMPI_MCA_foo=0 OMPI_MCA_foo=warning etc will work. A warning is printed for values not enumerated.
> - Support for system-administrator forced variables through the use of etc/openmpi-mca-params-override.conf. A warning is printed (which can be suppressed) for any attempt to override one of these values.
> - Support for variable scopes (constant, read-only, local, all, group, etc). Equivalent to MPI_T scopes.
> - Support for setting verbosity levels for each parameter. This will enable us to add a --level option to ompi_info to reduce the number of variables shown. Equivalent to MPI_T verbosity.
> - Renamed the read_only attribute for parameters to default only. This name better reflects the meaning of these variables.
> - Variables are now broken down by group. A group is a project, framework, or component. Ex: opal, opal_shmem, opal_shmem_mmap. Groups are automatically registered when a variable is registered. You can set a description for a group by calling mca_base_var_group_register before registering any variables. Groups are equivalent to MPI_T categories.
> - Variables must be registered with a backing store that must live at least as long as the variable (no stack variables-- unless of course they are deregistered before return). This means changes to a variable made with mca_base_var_set_value() will be immediately visible in the registered storage. There is no need to "lookup" the value.
> - Environment and file values are only looked up at registration time. After registration a variable can change by either: 1) the registree changes the value, or 2) the value is changed with mca_base_var_set_value().
> - File values are preserved in mca_base_var_file_values so there is no longer a need to recache files. The values are still stored in an opal_list_t. Since the list is only referenced at registration time this shouldn't be an issues.
> - etc
> Why: This RFC is one of a number of RFCs that will eventually bring full support for the MPI tool interface to Open MPI. This change is intended to support the entirely of the MPI tools control variable API (except MPI_T_cvar_write-- that will be supported by a future update). A quick background for this change: the MCA parameter system needed to be augmented to support a number of MPI_T functionality (scope, verbosity, etc). After some discussion Jeff and I decided now would be a good time to greenfield the interface. Given the complexity of the change we will reserve time during the next con-call for further discussion on the why and the what.
> When: Given the size of this change I want to give this a fairly long timeout. Timeout set for Feb 13 @ 1:00 PM EST.
> Please take some time to evaluate the new interface. Let me know if there is anything that can be done to further improve the interface.
> As a heads up. If you have a component that registers any variables please define a mca_register_component_params for your component and move all parameter registration into that function. It will save me a lot of time later.
> -Nathan Hjelm
> <mca_base_var_v1.patch>_______________________________________________
> devel mailing list
> devel_at_[hidden]

Jeff Squyres
For corporate legal information go to: