Feature Request: Expose PU APIC ID in hwloc API

[rsagashe03]

I’d like to request support for exposing the APIC ID of Processing Units (PUs) through the public hwloc API.

Currently, APIC IDs are discovered and stored internally by the x86 backend (e.g., in struct procinfo as infos[i].apicid), but this data is not made accessible through the public API.

Motivation:APIC IDs are useful for many low-level system programming tasks:

It is stable across OSes because it's independent of it, and thus it can also be matched to BIOS/UEFI content.

pinning threads to specific dies or cores based on APIC layout

Proposed Solution:

It would be helpful if hwloc could make the APIC ID available through the below option:

Add an apic_id field to the hwloc_obj->attr structure for PU objects

[bgoglin]

Hello.
I actually thought about this several times in the past but I never found a use case. If you have a use case, that's indeed fairly easy to add.

What bothers me a bit with pu->attr->pu.apic_id is that we may need another field if non-x86 architecture ever want to expose another hardware index. However, finding a more portable name is hard. "hw_index" would be very confusing with our OS index since it often described as "physical index".

One possibility would be to put a union in front of it, something like

struct hwloc_pu_attr_s {
  union <find a good name> {
    uint64_t apic_id; /* uint64_t in case a future member of the union has be huge */
  } <find a good name>;
}

Another solution would be to add it as a key value pair in each PU only on x86: "APICID=24". But that's harder to use for applications.

Or don't bother since we have enough room to store apic_id and something else for non-x86, but make it -1 when not available.

By the way, I know the APIC ID is also available in /proc/cpuinfo but there's the "initial" one and another one, but I don't remember the difference.

[rsagashe03]

In that case, I’d definitely support the simpler approach of just adding an apic_id field directly to struct hwloc_pu_attr_s, and setting it to -1 when unavailable or irrelevant (e.g., on non-x86). That keeps things easy to access for applications without needing to parse stringified info attributes, while still allowing future flexibility if needed.

If another architecture later needs its own ID field, the struct could evolve naturally, or apic_id could be reused under a more generic name if needed down the line

Let me know if you'd like a patch or if you'd prefer to handle it upstream.

[bgoglin]

Note to myself when I'll implement this: initial_apicid is read from early boot, possibly without all features enabled/used, and later replaced by the actual apicid, so we only want the real apicid, not the initial one.