Expose E/P core information though ResourceAggregator

[ozhuraki]

Modify ResourceAggregator to advertise new resources for each cpu type in each Zone (NUMA node) by mapping generic k8s cpu resource to each cpu_type.

[ffromani]

/cc

[ffromani]

Hi! I'm not clear about the requirement. Do you want to

• just advertise there are E cores and P cores (aka not all CPUs are equal?)
• advertise how many E core and P core are allocated/available (aka split the cpu resource)?
• anything else?

cc @PiotrProkop @marquiz @kad

[ozhuraki]

@ffromani @PiotrProkop

just advertise there are E cores and P cores (aka not all CPUs are equal?)

In a simplest case, yes. This is already in #1737

advertise how many E core and P core are allocated/available (aka split the cpu resource)?

In principle, this is already in #1737 too (we expose core IDs for each core type)

anything else?

If I understood @PiotrProkop thought to add this information to NRT object in order advertise new resources for each cpu type in each Zone (NUMA node) by mapping generic k8s cpu resource to each cpu_type.

[kad]

Initial requirement was for out-of-tree components to get information about node, to know which cpu number is which type.
Those CPU types are usually single sockets, so it is not really mapped to "NUMA" node.
For just marking the node, we had boolean label "node has hybrid cpu cores". So, that mentioned initial request was about exposing a bit more details over nfd.

[ffromani]

I see the value in exposing this information, it fits in the "export more detailed topology information than the default k8s resource model" that nfd-topology-updater is alla about.
I think that this is a good option to leverage and make good use of the great flexibility the API grants. Rather than shoehorning the values as attributes, or moving them in the existing NUMA zone reporting (IIUC this is a poor fit), I'd explore the option to add completely new zones describing the E/P split and count.
After all, we designed the API to allow this form of flexibility from day 1.

[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