summaryrefslogtreecommitdiff
path: root/kernel/locking/rtmutex_api.c
diff options
context:
space:
mode:
authorVlad Dumitrescu <vdumitrescu@nvidia.com>2025-06-30 13:16:44 +0300
committerLeon Romanovsky <leon@kernel.org>2025-07-09 02:51:35 -0400
commit8ab05a5456bb9556bbf7d500a4b1b3b261ed6894 (patch)
tree608d8c883176fd4de7f599e16812f0e7fb902e59 /kernel/locking/rtmutex_api.c
parent314cb74cea847db6226f3eaba4167198501d7ba3 (diff)
IB/cm: Use separate agent w/o flow control for REP
Most responses (e.g., RTU) are not subject to flow control, as there is no further response expected. However, REPs are both requests (waiting for RTUs) and responses (being waited by REQs). With agent-level flow control added to the MAD layer, REPs can get delayed by outstanding REQs. This can cause a problem in a scenario such as 2 hosts connecting to each other at the same time. Both hosts fill the flow control outstanding slots with REQs. The corresponding REPs are now blocked behind those REQs, and neither side can make progress until REQs time out. Add a separate MAD agent which is only used to send REPs. This agent does not have a recv_handler as it doesn't process responses nor does it register to receive requests. Disable flow control for agents w/o a recv_handler, as they aren't waiting for responses. This allows the newly added REP agent to send even when clients are slow to generate RTU, which would be needed to unblock flow control outstanding slots. Relax check in ib_post_send_mad to allow retries for this agent. REPs will be retried by the MAD layer until CM layer receives a response (e.g., RTU) on the normal agent and cancels them. Suggested-by: Sean Hefty <shefty@nvidia.com> Reviewed-by: Maher Sanalla <msanalla@nvidia.com> Reviewed-by: Sean Hefty <shefty@nvidia.com> Signed-off-by: Vlad Dumitrescu <vdumitrescu@nvidia.com> Signed-off-by: Or Har-Toov <ohartoov@nvidia.com> Link: https://patch.msgid.link/9ac12d0842b849e2c8537d6e291ee0af9f79855c.1751278420.git.leon@kernel.org Signed-off-by: Leon Romanovsky <leon@kernel.org>
Diffstat (limited to 'kernel/locking/rtmutex_api.c')
0 files changed, 0 insertions, 0 deletions