Here's a thought that I've been kicking around in my head since we re-
started the PLPA conversation: if we're making an interesting and
useful API to query internal host topology information, should it
really be Linux-specific?
The PLPA was originally created to address a problem that was
specific to Linux (the fact that the API changed 3 times). But our
recent conversations are addressing a much wider range of issues
(topology stuff).
More specifically: perhaps PLPA 1.0.x is good exactly as it is. It's
a small, self-contained library that does one thing and does it
well. Adding plpa-taskset(1) is a Good evolutionary step, and still
preserves the idea that PLPA is a small, self-contained thing.
Perhaps the topology functionality should be separated into a
separate, cross-OS library (Linux, Solaris, Windows [gasp!]) that
would be genuinely useful for portable software authors (particular
as core counts are increasing).
Additionally, the PLPA API is somewhat tailored for Linux. The
Solaris affinity API, for example, is much richer / more feature-
full. It may not be useful to try to abstract all the affinity
functionality into a common library that represents the least common
denominator. The topology information can be returned in a common
way without loss of functionality, regardless of the OS's back-end
mechanism for delivering it.
The PLPA could still *use* libtopo (e.g., so that you can specify
socket/core tuples to plpa-taskset(1)), but the implementation of the
topology functionality would be logically separate (i.e., in a
library that plpa_taskset links against).
I admit some self-serving interests here: if we make this be a cross-
platform API, I can use it directly in Open MPI without needing to
put in a shim layer to translate between OMPI's internal data
structures/interface and libtopo, and it would work on multiple
platforms without needing to write more OMPI code.
--
Jeff Squyres
Cisco Systems
|
![[Flag]](../../../../../community/mirrors/flag-us.gif){kind=small}