feat: share virtual device count between hami-core and ENPU modes

[spencercjh]

What type of PR is this?

/kind bug

What this PR does / why we need it:

Use vnpus.deviceSplitCount for both hami-core and enpu, defaulting to 10, instead of deriving hami-core capacity from hard-slicing templates.

• A positive node vDeviceCount takes priority; ENPU caps the effective count at 100.
• Template mode keeps its template-based capacity calculation.
• The standalone Chart exposes deviceSplitCount.

Which issue(s) this PR fixes:

Fixes #128. Related: Project-HAMi/HAMi#2727.

Special notes for your reviewer:

Go tests and Helm checks passed. I plan to update the HAMi Chart in a follow-up PR after this PR is merged, including scheduler support for the renamed shared field. Codex assisted with implementation and validation.

Earlier Ascend-310P validation, before the shared-setting rename:

With a separate ConfigMap:

Does this PR introduce a user-facing change?:

Yes. Both soft-slicing modes default to 10 slots per NPU. ENPU previously defaulted to 100. Configuration now uses deviceSplitCount instead of vnpuDeviceSplitCount.

Summary by CodeRabbit

• New Features
  • HAMi vNPU-core and ENPU modes now support configurable virtual-device slots per physical NPU, defaulting to 10 when no positive split count is set.
  • A positive node-level virtual-device count takes precedence. ENPU counts are capped at 100; template mode continues to use template-derived capacity.
  • The Ascend device plugin chart exposes the split-count setting, with a minimum supported value of 1.
• Documentation
  • Updated deployment guides with configuration options, capacity behavior, and rollout requirements.

[hami-robot]

@spencercjh: The label(s) kind/bug cannot be applied, because the repository doesn't have them.

Details

In response to this:

What type of PR is this?

/kind bug

What this PR does / why we need it:

hami-core mode currently derives slot capacity from hard-slicing templates, limiting the reported 910B4-1 configuration to four slots per NPU even when memory and cores remain available.

• Use vnpus.vnpuDeviceSplitCount for hami-core slot capacity, defaulting to 10.
• A positive node vDeviceCount takes precedence.
• Template and ENPU capacity rules are unchanged.
• Update the standalone Chart and documentation.

Which issue(s) this PR fixes:

Fixes #128.

Related: Project-HAMi/HAMi#2727.

Special notes for your reviewer:

• I have tested it on an Ascend-310p cluster.
• Codex assisted with code, tests, documentation, and validation.

Does this PR introduce a user-facing change?:

Yes.

Without a positive node override, hami-core mode advertises 10 slots per NPU by default, configurable through vnpuDeviceSplitCount.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[coderabbitai]

Warning

Review limit reached

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Next included review available in 17 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 10414856-d9fe-4269-8cd5-897c72a807e9

📥 Commits

Reviewing files that changed from the base of the PR and between cd2f6f5 and cc3da71.

📒 Files selected for processing: 2

• charts/ascend-device-plugin/Chart.yaml
• charts/ascend-device-plugin/README.md

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 3f3c1759-6642-42da-abd8-beeec9280a75

📥 Commits

Reviewing files that changed from the base of the PR and between ab0c8ff and cd2f6f5.

📒 Files selected for processing: 10

• ascend-device-configmap.yaml
• charts/ascend-device-plugin/README.md
• charts/ascend-device-plugin/values.schema.json
• charts/ascend-device-plugin/values.yaml
• docs/hami.md
• docs/hami_cn.md
• internal/manager/manager.go
• internal/manager/manager_test.go
• internal/vnpu.go
• internal/vnpu_test.go

Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.

📝 Walkthrough

The change adds a configurable virtual-device split count for hami-core and ENPU modes. A positive node-level vDeviceCount takes precedence. Otherwise, the global count defaults to 10, and ENPU counts are capped at 100. Template mode retains its template-derived capacity.

Changes: Virtual-device split count

Layer / File(s)	Summary
Split-count configuration and documentation internal/vnpu.go, internal/vnpu_test.go, charts/ascend-device-plugin/values.yaml, charts/ascend-device-plugin/values.schema.json, ascend-device-configmap.yaml, charts/ascend-device-plugin/README.md, docs/hami.md, docs/hami_cn.md	Adds deviceSplitCount to the configuration and chart, with a chart default of 10 and a minimum value of 1. The generated configuration includes the chart value. Documentation describes count defaults, node-level precedence, ENPU’s cap, template-mode behavior, and restart and image requirements.
Mode selection and device registration internal/manager/manager.go, internal/manager/manager_test.go, internal/server/watch_and_register_test.go	VDeviceCount uses a positive node-level count first. Otherwise, hami-core and ENPU use the global split count, defaulting to 10; ENPU counts above 100 are capped. Template mode continues to use template-derived capacity. Tests cover mode selection, overrides, kubelet device counts and IDs, and HAMi registration counts.

Priority: ➖ Normal

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Feature · Severity of issue fixed: Medium

Sequence Diagram(s)

sequenceDiagram
  participant ConfigMap
  participant LoadConfig
  participant VDeviceCount
  participant apiDevices
  participant Kubelet
  participant registerHAMi
  participant HAMi
  ConfigMap->>LoadConfig: Provide deviceSplitCount
  LoadConfig->>VDeviceCount: Supply VNPUsConfig
  VDeviceCount->>apiDevices: Provide selected virtual-device count
  apiDevices->>Kubelet: Advertise healthy virtual-device IDs
  VDeviceCount->>registerHAMi: Provide per-device count
  registerHAMi->>HAMi: Register physical devices and counts

Loading

Suggested labels: enhancement

Merge Risk: ⚪ Minimal · up to cd2f6

The split-count setting appears consistent across configuration and device registration. No actionable merge-blocking issue remains after normal checks.

Pre-merge checks: 3 · 2

Failed checks: 2 warnings

Check name	Status	Explanation	Resolution
Out of Scope Changes check		The PR states that ENPU capacity rules remain unchanged. The supplied change summary instead states that ENPU now uses the global DeviceSplitCount and that its previous default of 100 changed to 10.…	Keep the configurable split-count change limited to hami-core. Preserve the previous ENPU default and capacity behavior, including its default of 100 and its existing cap, unless a separate ENPU requirement is added.
Docstring Coverage		Docstring coverage is 37.50% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 8 functions across 5 files. (6 skipped: 6…	Write docstrings for the functions missing them to satisfy the coverage threshold.

Passed checks: 3 passed

Check name	Status	Explanation
Linked Issues check		Issue #128 concerns the four-slot limit in Ascend hami-core mode. The supplied change summary shows that a positive node VDeviceCount now takes precedence, and hami-core otherwise uses `DeviceSplitC…
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.
Title check		The title clearly summarizes the main change: configuring and sharing virtual-device slot counts across hami-core and ENPU modes.

Full details: Out of Scope Changes check

Explanation

The PR states that ENPU capacity rules remain unchanged. The supplied change summary instead states that ENPU now uses the global DeviceSplitCount and that its previous default of 100 changed to 10. This is unrelated to issue #128 and changes ENPU behavior.

Full details: Docstring Coverage

Explanation

Docstring coverage is 37.50% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 8 functions across 5 files. (6 skipped: 6 unsupported.)

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{A rabbit counts the slots in rows,
Ten virtual doors for each NPU shows.
A node may set a different score,
ENPU stops at one hundred, no more.
Template mode keeps its own design,
And registered counts mark the line.
Hop, config travels down the chain!}

_{Comment @coderabbitai help to get the list of available commands.}

[spencercjh]

/assign @DSFans2014

[spencercjh]

/assign @archlitchi

[spencercjh]

/assign @Shouren

[FouoF]

/lgtm

[archlitchi]

/lgtm

[hami-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: archlitchi, spencercjh

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [archlitchi]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment