Developer Notes

Symbol Conflicts

The hwloc is loaded into the public linker name space to support hwloc plugins. This might have unintended consequences.

Design Decisions

Some design decisions were made in the initial development phase. For instance, whether something should be a Python attribute or a Python method. My choice at the time was simple, if it’s part of a C struct, it’s an attribute, otherwise, it’s a function. If both are possible, like the cpuset and the pci_id, we use property. This way, we can keep it simple and allow future extension for parameters. It’s ok, Python stdlib does not use property very often, let’s move on.

Hwloc has lots of setters and getters, some Python users might frown upon this design pattern, but we decided keep it instead. Most of these setters and getters have parameters. We could have wrapped them into properties like:

topology.membind[proc_id] = Membind(policy, flags)

It might be more ergonomic this way, but also feels like an un-intuitive way to writing code. In addition, the setter and getters don’t have exact match. For instance, setting the DEFAULT policy with the membind setter might get you a FIRST_TOUCH policy in the getter.

For interpolation modules, hwloc supports getting the CPU affinity of GPUs with functions like nvml_get_device_cpuset. We rename the function in the high-level interface as get_affinity to avoid confusion.