You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 7175f8c
Browse filesBrowse the repository at this point in the historyBrowse files
fix(rdma): move real bytes on the staging and GPU-direct paths
The RDMA data plane reported success for transfers that moved nothing.
Four defects, each of which independently made a green run meaningless.
buildRdmaToken advertised mr->addr. ibv_reg_dmabuf_mr leaves that NULL,
and on the bounce path it is the staging buffer rather than the caller's
pointer, so the token described memory the peer could not use. BufferMap
now records the address to advertise at registration time.
Nothing copied between the caller's buffer and the staging buffer. When
the NIC cannot reach GPU memory directly, hipObject registers host
staging instead of the caller's pointer -- and then left it empty. Adds
hipObjBufSync: callers driving a transfer through hipObjGetRdmaToken call
it with HIPOBJ_SYNC_TO_HOST before a PUT and HIPOBJ_SYNC_TO_DEVICE after
a GET. It is a no-op for a directly registered buffer.
The minio-cpp bridge sent the caller's raw pointer in the token's
":<addr>:<len>" suffix, which rocm-ernic treats as an override of the
address in the token. On the staging path that address is not covered by
the MR, giving LOCAL_PROT_ERR and a zero-byte transfer that the bridge
reported as success. Send zeros -- "no override" -- and let the token
speak. rdmaPutWithRetry now stages to host before the request and
rdmaGetWithRetry stages back to device after a successful reply.
dmabuf support was predicted rather than attempted.
init_dmabuf_support_flag() grepped /boot/config-$(uname -r) for both
CONFIG_DMABUF_MOVE_NOTIFY=y and CONFIG_PCI_P2PDMA=y, and switched the
whole GPU-direct path off when either was missing. Measured on
7.2.4-070204-generic: PCI_P2PDMA is set, ibv_reg_dmabuf_mr resolves in
rdma-core 61.0, hsa_amd_portable_export_dmabuf succeeds -- and
DMABUF_MOVE_NOTIFY is simply absent from the config. One missing line
turned off a path that works. The gate is gone; the call is tried and its
result believed.
With that, a GPU-direct transfer that cannot be done directly must not be
quietly done some other way. HIPOBJ_REQUIRE_GPU_DIRECT=1 makes the client
refuse to fall back to host staging for a device pointer, and say so,
rather than return success for a transfer the caller did not ask for.
This is what turns the GPU Direct CI lane red: it was passing by faking.
Failures also say which failure. Every RDMA error used to surface as one
anonymous -1, which the HTTP layer rendered as "500 RDMA PUT failed" --
six distinct faults, from an unparseable token to a completion error,
indistinguishable from a server with no RDMA at all. pollCompletion now
reports the work-completion status, opcode and vendor_err, and each
failure path names itself.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: Stephen Bates <sbates@raithlin.com>
0 commit comments