This FAQ is for Open MPI v4.x and earlier.
If you are looking for documentation for Open MPI v5.x and later, please visit docs.open-mpi.org.
Table of contents:
- What is the future of the PLPA?
- What is the API provided by the PLPA?
- Can I include the PLPA in my software project?
- How does the PLPA figure out which kernel API to use?
- I'm having a problem! What should I do?
| 1. What is the future of the PLPA? |
The PLPA project is (or will be soon) deprecated by the Portable Hardware Locality (hwloc)
project.
To be clear: all future development work is going into hwloc. See the
hwloc project announcements here
and here.
The first release of hwloc won't contain all of the PLPA
functionality; the ideas of PLPA are being slowly imported into hwloc
over time. For example, PLPA's embedding capabilities will definitely
not be in the first hwloc release -- but embedding is a feature in
hwloc's short-term roadmap (Editor's note: I wouldn't consider hwloc a
wholesale replacement for PLPA until embedding is available).
The PLPA API likely will not be directly carried over to hwloc; hwloc
already has its own API that will likely be extended over time to
include PLPA concepts. Hence, there will be a (small) porting effort
involved in converting PLPA-based applications to hwloc.
Please see the hwloc project
page and/or subscribe to the hwloc mailing lists for
more information.
| 2. What is the API provided by the PLPA? |
The API provides a small number of C functions and
preprocessor macros. The API is best described through its header
file:
| 3. Can I include the PLPA in my software project? |
Yes.
The PLPA was specifically designed to be safely included in other
software projects. The PLPA provides an M4 macro file suitable for
acinclude'ing in a top-level configure script, and also has a
name-shifting mechanism for its API so that if multiple libraries
include name-shifted versions of the PLPA, there will be no symbol
conflicts.
The PLPA README file has more details on the name shifting
mechanism.
The PLPA is licensed under the BSD license.
| 4. How does the PLPA figure out which kernel API to use? |
The PLPA uses the syscall() interface to bypass GLibc and
directly call the get and set affinity functions in the Linux kernel.
This is because the GLibc API has changed multiple times, and there
are buggy versions in real linux distributions that cause problems.
Bypassing it and directly callign the kernel seemed the safest route.
But even so, the kernel has slightly changed its API a few times.
Mostly, this has to deal with the len parameter (telling the kernel
how long the CPU set argument it). Careful examiniation of the kernel
source code has led to a fairly small number of safe tests that can be
performed to determine which size it expects.
The PLPA hides all this from the user -- it will figure out what size
the kernel expects and use it in all the syscall() interactions with
the set and get affinity functions.
| 5. I'm having a problem! What should I do? |
If you can't get the PLPA to compile, please see the Open MPI
Getting Help page to see what
details to send to the PLPA User's Mailing
List.
If you are having problems with the PLPA run-time, please send a detailed message the PLPA User's Mailing
List describing what is going wrong. The more information that
you provide, the better. Mails saying "It doesn't work -- help me!"
will simply be met with requests for more information, so please just
sent it all the first time.
Please be sure to include the output of plpa_info in your message.
|
