Skip to content

gdrcopy: fall back to the v1 pin API when the v2 pin ioctl is unsupported (gdrdrv < 2.5) - #1354

Open
dmvevents wants to merge 1 commit into
aws:masterfrom
dmvevents:feat/gdrcopy-forced-pcie-override
Open

gdrcopy: fall back to the v1 pin API when the v2 pin ioctl is unsupported (gdrdrv < 2.5)#1354
dmvevents wants to merge 1 commit into
aws:masterfrom
dmvevents:feat/gdrcopy-forced-pcie-override

Conversation

@dmvevents

@dmvevents dmvevents commented Aug 14, 2026

Copy link
Copy Markdown

Issue #, if available: #1350

Description of changes:

Scoped down to avoid overlapping #1351 (which carries the OFI_NCCL_GDRCOPY_FORCED_PCIE_COPY env override and the probe unification). This PR is now only the v1 pin fallback — the second half of the #1350 fix, composing with #1351:

On a host whose gdrdrv kernel module predates 2.5 while userspace libgdrapi is 2.5+ (a common pairing on fleet AMIs), gdr_pin_buffer_v2 resolves fine at init, but the v2 pin ioctl is not recognized by the kernel and fails with EINVAL/ENOTTY at registration time. This change falls back to the v1 pin API in that case instead of failing the registration; the two are identical at the gdr_mh_t output level (only the flags input differs).

Why both halves are needed (measured, mixed 2-node p5en fleet — one gdrdrv 2.5, one 2.4, libgdrapi 2.5.2 on both):

#1351 override alone + this fallback
GIN init gate on the 2.4 node passes (capability asserted) passes
buffer registration on the 2.4 node v2 pin ioctl fails → registration error v1 pin succeeds
workload faults DeepEP dispatch/combine correctness gate PASS, exit 0 both nodes, zero CUDA 719 combine faults

Inert everywhere the v2 ioctl works: the fallback only fires on EINVAL/ENOTTY from the v2 pin call.

Draft pending maintainer read on #1350/#1351 — if you'd rather fold this hunk into #1351 as one PR, happy to do that instead.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

…rted

On a host whose gdrdrv kernel module predates 2.5 while userspace
libgdrapi is 2.5+ (a common pairing on fleet AMIs), gdr_pin_buffer_v2
resolves fine at init but the v2 pin ioctl is not recognized by the
kernel and fails with EINVAL/ENOTTY at registration time. Fall back to
the v1 pin API in that case instead of failing the registration; the
two are identical at the gdr_mh_t output level (only the flags input
differs).

This composes with the OFI_NCCL_GDRCOPY_FORCED_PCIE_COPY override
(aws#1351): the override asserts the capability on a min(runtime, driver)
probe miss, and this fallback makes the pin path actually work on the
gdrdrv-2.4 kernels that miss. Measured on a mixed 2-node p5en fleet
(one gdrdrv 2.5, one 2.4, libgdrapi 2.5.2 both): with both changes, 24x
'Assigned GIN plugin' on both nodes and the DeepEP dispatch/combine
correctness gate passes with zero CUDA 719 combine faults; without the
fallback the 2.4 node fails registration.

Refs: aws#1350
Signed-off-by: Anton Alexander <dmvevents@gmail.com>
@dmvevents
dmvevents force-pushed the feat/gdrcopy-forced-pcie-override branch from 01a7c40 to b4a9ddf Compare August 14, 2026 17:03
@dmvevents dmvevents changed the title gdrcopy: env override for forced-PCIe probe + v1 pin fallback on gdrdrv 2.4 gdrcopy: fall back to the v1 pin API when the v2 pin ioctl is unsupported (gdrdrv < 2.5) Aug 14, 2026
@dmvevents
dmvevents marked this pull request as ready for review August 14, 2026 17:20
@dmvevents
dmvevents requested a review from a team as a code owner August 14, 2026 17:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant