Publish x86-64 microarchitecture level instead of cpuid features

[boniek83]

What would you like to be added: add x86-64 microarchitecture level label and blacklist all other cpuid features by default except for cpuid features newer than x86-64v4. Why is this needed: Less clutter, more useful labels.

[marquiz]

@boniek83 I agree with the issue about clutter/bloat. Not sure how we should address this, though. I'm not sure we can meaningfully map cpu flags to certain uarch level. Also, I'm not very fond of starting to maintain a mapping/database of cpu features.

Some options come to my mind:

1. We already have the default denylist -> extend it to drop more features
2. Change from default denylist to allowlist -> only enable some hand-picked cpuid labels by default
3. Additionally, we could support globbing for the deny/allow list to make configuration a tad easier

Thoughts? /cc @ozhuraki

[boniek83]

Wiki has decent article about it: https://en.wikipedia.org/wiki/X86-64 (Microarchitecture levels) and that is how I do it now using nfd rules. It seems like a one time effort per uarch level and it's not like there is new uarch level every year. I personally don't care at all about cpu features if I have uarch levels (except for features that are newer that newest uarch level). I wonder if adding all flags to default denylist won't make my uarch level rules stop working though.

[ozhuraki]

@marquiz @boniek83

Thanks for the input.

I would propose we first just expose the microarchitecture level as a label.

The blacklisting could be done as a configurable option (disabled by default).

What do you think?

[marquiz]

The list on the wiki page is not exhaustive and not all all cpuid flags map to any particular uarch level. Sleeping over this I think @boniek83 your original suggestion would probably be good, just add the old uninteresting features to the default blacklist.

One possible bonus how to improve the usability would be to make it possible to users more easily to disable/enable certain flags, like

attributeList:
 - "-AVX2"
 - "+TDX_GUEST"

...probably a bad ui example but you get the idea.

One possiblity (for the bonus feature) would be to deprecate the attributeBlacklist and attributeWhitelist configs and replace with deny list` and allow list configs which could be used to modify the built-in default list of allowed cpuid attributes.

deny:
- "AVX2"
allow:
- "TDX_GUEST"

[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

[jcpunk]

/remove-lifecycle rotten

I'd still like to see some version of this.