Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MCA component filter #1974

Closed
wants to merge 2 commits into from
Closed

MCA component filter #1974

wants to merge 2 commits into from

Conversation

hjelmn
Copy link
Member

@hjelmn hjelmn commented Aug 17, 2016

This RFC is based on discussion on how to add a top-level component (ala --net) to Open MPI to enable or disable all components of a particular network type. This is a work in progress and will likely evolve.

hjelmn added 2 commits August 16, 2016 21:35
This commit adds support to the MCA base to filter components based
on a filter this. In this version there are two types of filters:
enable, and disable. If a component's filter matches a disable list
then the component is disabled. If a component matches an enable list
it is used. We will need to further discuss this behavior before it
is ready for master.

Signed-off-by: Nathan Hjelm <hjelmn@me.com>
This commit adds filters to all the available network components. This
is a proof of concept and will evolve as the filter support does.

Signed-off-by: Nathan Hjelm <hjelmn@me.com>
@hjelmn
Copy link
Member Author

hjelmn commented Aug 17, 2016

@jjhursey This is a working example of the low-level support needed for --net. The enable functionality is not quite ready but disable works. For example --mca mca_base_component_disable shared-memory disables btl/sm and btl/vader.

@hjelmn
Copy link
Member Author

hjelmn commented Aug 17, 2016

One way this diverges from what we discussed is I put a mxm filter on all mxm components. I did this to give a better example of how filtering could be done.

@jjhursey
Copy link
Member

A few notes from the discussion in the Open MPI Developer's meeting:

  • If I disable tcp does that disable it for the ORTE daemons. Maybe this is just for the MPI application.
    • Two users of a common set of functionality (btl) that might make different decisions: osc and ob1
  • What is the (expansiveness of) intent of the end user when they specify an option?
  • disable is easy and done.
  • enable is more difficult. Maybe we need a net: prefix to the keys. Central issue is what about components that do not supply any flags and how do we know to ignore ib when enabling tcp?
  • Should we approach this as a call down model from the framework, instead of built into the low level logic? top level filtering approach
    • orte took a similar approach that might be simpler when you get into the weeds of details
  • Open question: is there a use case to not dlopen the component? We would need to add a metadata structure parallel to the .so

Copy link
Member

@jsquyres jsquyres left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add a Signed-off-by line to this PR's commit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants