Open MPI logo

PLPA Overview:
General information about the PLPA

  |   Home   |   Support   |   FAQ   |  

Table of contents:

  1. What is the future of the PLPA?
  2. What is the API provided by the PLPA?
  3. Can I include the PLPA in my software project?
  4. How does the PLPA figure out which kernel API to use?
  5. 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.