[TransferEngine] Clamp RDMA QP atomic depths to device limits - #3977
Draft
junyyang-amd wants to merge 1 commit into
Draft
junyyang-amd wants to merge 1 commit into
junyyang-amd wants to merge 1 commit into
Conversation
Use the device responder budget and per-QP limits when selecting RTR and RTS atomic depths. Ionic devices advertise 16 shared responder resources, so reserving the previous fixed depth of 16 can prevent a second QP from reaching RTR. Port the QP compatibility fix from Jasen2201/Mooncake to upstream main, with capability regression coverage. The nominal 16-QP budget is a conservative per-QP policy, not global resource admission control.
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.
Description
Creating multiple RC QPs can fail on AMD Pensando Ionic devices with
Failed to modify QP to RTR ... Invalid argument. These devices advertisemax_res_rd_atom=16for the whole device, while Transfer Engine currently requests a responder depth of 16 for every QP. The first QP can exhaust that budget, preventing even the second QP of an endpoint from reaching RTR.Select the responder and initiator depths from the queried device capabilities and use them in the RTR/RTS transitions:
max_qp_rd_atom.max_qp_init_rd_atom; preserve zero capabilities.On Ionic with all three capabilities equal to 16, this selects responder/initiator depths of 1/1 instead of 16/16. Devices with sufficient shared and per-QP capacity retain 16/16. Devices with smaller budgets may trade read concurrency for QP availability. This is a conservative per-QP allocation policy; it does not implement device-wide admission control across arbitrary endpoint/process counts or negotiate depths with heterogeneous peers.
Module
mooncake-transfer-engine)Type of Change
How Has This Been Tested?
Validation against upstream main
b9059252aa8db150ada8220241707d47e27ebb79plus this patch, usingrocm/atom-dev:mooncake_v0.3.14-rc1as the build environment:rdma_endpoint_state_test: 8 passed.rdma_context_reprobe_test: 18 passed, including all nine added cases; 1 existing XDR test skipped because the installed RDMA headers lack extended speed support.USE_HIP=ON,USE_HIP_DMABUF=ON,BUILD_UNIT_TESTS=OFF, andBUILD_EXAMPLES=ON(otherwise the same configuration). CMake reportedHIP dmabuf MR registration enabled (hsa-runtime64 found).