feature request: socket topology

[vsoch]

hiya! I'm looking to get a mapping of which cores belong to which socket, akin to what hwloc does: https://www.open-mpi.org/projects/hwloc/doc/v0.9.3/

Right now it looks like nfd exposes a cpu -> topology.socket_count which is great, but doesn't tell us about the topology. Would this be possible? Thanks!

[vsoch]

I'm also not seeing basics about number of physical vs logical cores - that seems obvious like it should be here?

[marquiz]

The node labels are not suitable for describing detailed hardware topology. I also think that the NodeFeature CRD isn't a very good at that. There's a separate nfd-topology-updater daemon that would be a better target for this feature – it exposes the topology via a separate CRD called NodeResourceTopology. The topology-updater currently exposes NUMA nodes only, not other aspects of the HW topology.

What is your use case for this request? How are you planning to consume the information?

[vsoch]

I’m working on the compatibility specification for OCI and building extractor plugins and tools, for Kubernetes but also HPC. For a lot of HPC applications we want to know the detailed topology to best schedule work. https://www-hpc.cea.fr/tgcc-public/en/html/toc/fulldoc/Process_distribution_affinity_binding.html

[vsoch]

It could be that hwloc is a better fit for this - I found a library in go but it has a bug so I opened an issue.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[TessaIO]

/remove-lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[TessaIO]

/remove-lifecycle stale