[None][perf] Gate NCCL NVLS on NVML fabric state, not IMEX availability#16595
Open
Wanli-Jiang wants to merge 1 commit into
Open
[None][perf] Gate NCCL NVLS on NVML fabric state, not IMEX availability#16595Wanli-Jiang wants to merge 1 commit into
Wanli-Jiang wants to merge 1 commit into
Conversation
The NCCL NVLS gate required getMemHandleType() to resolve to FABRIC, i.e. a fully provisioned IMEX plane. That is stricter than what an NVLS multicast bind actually needs: on single-node systems the bind works over POSIX-FD handles without IMEX, so nodes with a healthy switch fabric but no IMEX (e.g. HGX B200 containers without nvidia-imex) lost NVLS- accelerated NCCL for no reason. Split the NVML fabric-state check out of getMemHandleType() and gate NCCL NVLS on it directly (ipcNvlsUsable, formerly ipcNvlsFabricUsable): the static multicast capability plus a COMPLETED NVLink fabric registration -- Fabric Manager has configured the switch -- is the actual precondition for a successful single-node bind. Multi-node sessions (detected by comparing the session size with the per-host local session size, both materialized at MPI init) keep the full IMEX requirement, because cross-node multicast memory can only be shared via FABRIC handles. The unprovisioned-fabric nodes that PR NVIDIA#15302 protects against (bind failure poisons the CUDA context and hangs startup) do not reach the COMPLETED state and stay disabled, with the warning split into a fabric-state variant and a multi-node IMEX variant. An explicit NCCL_NVLS_ENABLE setting now skips the check and the warning in getComm() as well, matching NcclCommunicator::createComm. ipcNvlsSupported() and the ipcNvlsAllocate() path are untouched, so the single-node POSIX-FD allocator restored by PR NVIDIA#15882 is unaffected, and the ipcNvlsMemoryTest regression guards it added still pass. Verified on 4xB200 (fabric state COMPLETED, no IMEX): a direct cuMulticastCreate/AddDevice/BindMem probe over POSIX-FD succeeds, and with NVLS enabled NCCL reports "NVLS multicast support is available" with 24 NVLS channels while the BART tp2 end-to-end test passes. On 4xH200 NVL (no NVSwitch, MULTICAST_SUPPORTED=0): NVLS stays disabled with no warning, BART tp2 passes, and ipcNvlsMemoryTest passes 2/2. Explicitly setting NCCL_NVLS_ENABLE=0 or =1 skips the probe and warning entirely. Signed-off-by: Wanli Jiang <35160485+Wanli-Jiang@users.noreply.github.com>
Wanli-Jiang
force-pushed
the
user/williamj/nccl-nvls-bind-probe
branch
from
July 20, 2026 06:36
b19ff54 to
490c563
Compare
Wanli-Jiang
marked this pull request as ready for review
July 20, 2026 06:37
Collaborator
Author
|
/bot run --disable-fail-fast |
Collaborator
|
PR_Github #60296 [ run ] triggered by Bot. Commit: |
Contributor
📝 WalkthroughWalkthroughNVLS runtime checks now distinguish static multicast support from fabric registration and session topology. Fabric-aware memory handle selection is cached, while NCCL communicator setup centrally disables NVLS when the session cannot use it. Tests now validate the updated usability contract. ChangesNVLS usability and NCCL gating
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant getComm
participant NcclCommunicator
participant maybeDisableNcclNvls
participant nvlsUsability
participant NCCL
getComm->>maybeDisableNcclNvls: prepare NCCL NVLS
NcclCommunicator->>maybeDisableNcclNvls: prepare NCCL NVLS
maybeDisableNcclNvls->>nvlsUsability: query cached session usability
nvlsUsability-->>maybeDisableNcclNvls: usable or unusable state
maybeDisableNcclNvls->>NCCL: set NCCL_NVLS_ENABLE=0 when unusable
getComm->>NCCL: initialize communicator
NcclCommunicator->>NCCL: initialize communicator
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Collaborator
|
PR_Github #60296 [ run ] completed with state
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The NCCL NVLS gate required getMemHandleType() to resolve to FABRIC, i.e. a fully provisioned IMEX plane. That is stricter than what an NVLS multicast bind actually needs: on single-node systems the bind works over POSIX-FD handles without IMEX, so nodes with a healthy switch fabric but no IMEX (e.g. HGX B200 containers without nvidia-imex) lost NVLS- accelerated NCCL for no reason.
Split the NVML fabric-state check out of getMemHandleType() and gate NCCL NVLS on it directly (ipcNvlsUsable, formerly ipcNvlsFabricUsable): the static multicast capability plus a COMPLETED NVLink fabric registration -- Fabric Manager has configured the switch -- is the actual precondition for a successful single-node bind. Multi-node sessions (detected by comparing the session size with the per-host local session size, both materialized at MPI init) keep the full IMEX requirement, because cross-node multicast memory can only be shared via FABRIC handles. The unprovisioned-fabric nodes that PR #15302 protects against (bind failure poisons the CUDA context and hangs startup) do not reach the COMPLETED state and stay disabled, with the warning split into a fabric-state variant and a multi-node IMEX variant. An explicit NCCL_NVLS_ENABLE setting now skips the check and the warning in getComm() as well, matching NcclCommunicator::createComm.
ipcNvlsSupported() and the ipcNvlsAllocate() path are untouched, so the single-node POSIX-FD allocator restored by PR #15882 is unaffected, and the ipcNvlsMemoryTest regression guards it added still pass.
Verified on 4xB200 (fabric state COMPLETED, no IMEX): a direct cuMulticastCreate/AddDevice/BindMem probe over POSIX-FD succeeds, and with NVLS enabled NCCL reports "NVLS multicast support is available" with 24 NVLS channels while the BART tp2 end-to-end test passes. On 4xH200 NVL (no NVSwitch, MULTICAST_SUPPORTED=0): NVLS stays disabled with no warning, BART tp2 passes, and ipcNvlsMemoryTest passes 2/2. Explicitly setting NCCL_NVLS_ENABLE=0 or =1 skips the probe and warning entirely.
Summary by CodeRabbit
Description
Test Coverage
PR Checklist
Please review the following before submitting your PR:
PR description clearly explains what and why. If using CodeRabbit's summary, please make sure it makes sense.
PR Follows TRT-LLM CODING GUIDELINES to the best of your knowledge.
Test cases are provided for new code paths (see test instructions)
If PR introduces API changes, an appropriate PR label is added - either
api-compatibleorapi-breaking. Forapi-breaking, includeBREAKINGin the PR title.Any new dependencies have been scanned for license and vulnerabilities
CODEOWNERS updated if ownership changes
Documentation updated as needed
Update tava architecture diagram if there is a significant design change in PR.
The reviewers assigned automatically/manually are appropriate for the PR.
Please check this after reviewing the above items as appropriate for this PR.
GitHub Bot Help
To see a list of available CI bot commands, please comment
/bot help.