From: Michael Bommarito <michael.bommarito@gmail.com>
To: Jason Gunthorpe <jgg@nvidia.com>, Leon Romanovsky <leonro@nvidia.com>
Cc: linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, Vlad Dumitrescu <vdumitrescu@nvidia.com>,
Or Har-Toov <ohartoov@nvidia.com>,
Bob Pearson <rpearsonhpe@gmail.com>,
Sean Hefty <shefty@nvidia.com>, Kees Cook <kees@kernel.org>
Subject: [PATCH v2] IB/mad: cap RMPP reassembly window size
Date: Wed, 20 May 2026 11:47:15 -0400 [thread overview]
Message-ID: <20260520154715.1457495-1-michael.bommarito@gmail.com> (raw)
In-Reply-To: <20260518212336.337104-1-michael.bommarito@gmail.com>
find_seg_location() inserts reordered RMPP DATA segments into a
per-transaction list by walking that list in reverse. The walk runs
under rmpp_recv->lock in the MAD receive worker, so a large receive
window makes a reversed RMPP burst expensive.
The receive window comes from recv_queue.max_active. With the default
recv_queue_size of 512, the window is 64. Larger tuned queues can raise
the window to 1024, turning one reordered transaction into repeated
long list walks and keeping the target port's MAD worker busy for
milliseconds.
Cap the RMPP window at 64, matching the current default. This keeps
existing behavior for default configurations and prevents larger receive
queues from increasing the worst-case insertion walk.
Fixes: fa619a77046b ("[PATCH] IB: Add RMPP implementation")
Cc: stable@vger.kernel.org
Assisted-by: Codex:gpt-5-5-xhigh
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
---
Impact: a fabric peer that can send QP1 GMP RMPP DATA segments can keep
the targeted port's MAD worker busy with reordered RMPP bursts, delaying
other MAD processing on that port.
I tested this on v7.1-rc2 under x86_64 QEMU/KVM with rxe and raw RoCEv2
packets carrying descending RMPP segment numbers. With
recv_queue_size=8192, the unpatched kernel spent at least 1.5 ms per
F=1024 burst in the insertion walk; the patched kernel dropped the same
run to about 0.28 ms because segments outside the capped window are
rejected before the list grows. A normal in-window F=32 RMPP exchange
still completed; there are no in-tree selftests for QP1 GMP RMPP
reassembly in tools/testing/selftests/drivers/net/rdma.
Changes in v2:
- Rewrite the commit message in shorter, plain language.
- Trim the code comment to the local reason for the cap.
drivers/infiniband/core/mad_rmpp.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/core/mad_rmpp.c b/drivers/infiniband/core/mad_rmpp.c
index 17c4c52a19e4c..0db645eb2e29b 100644
--- a/drivers/infiniband/core/mad_rmpp.c
+++ b/drivers/infiniband/core/mad_rmpp.c
@@ -391,9 +391,18 @@ static inline struct ib_mad_recv_buf *get_next_seg(struct list_head *rmpp_list,
return container_of(seg->list.next, struct ib_mad_recv_buf, list);
}
+/*
+ * find_seg_location() is linear in the number of queued segments.
+ * Keep the RMPP window at the default size so a larger receive queue
+ * does not also enlarge the reordered DATA insertion walk.
+ */
+#define IB_MAD_RMPP_MAX_WINDOW 64
+
static inline int window_size(struct ib_mad_agent_private *agent)
{
- return max(agent->qp_info->recv_queue.max_active >> 3, 1);
+ int wsize = agent->qp_info->recv_queue.max_active >> 3;
+
+ return clamp(wsize, 1, IB_MAD_RMPP_MAX_WINDOW);
}
static struct ib_mad_recv_buf *find_seg_location(struct list_head *rmpp_list,
--
2.53.0
next prev parent reply other threads:[~2026-05-20 15:47 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-18 21:23 [PATCH] IB/mad: cap RMPP reassembly window size to bound find_seg_location walk Michael Bommarito
2026-05-19 14:46 ` Leon Romanovsky
2026-05-20 15:47 ` Michael Bommarito [this message]
2026-06-03 17:54 ` [PATCH v2] IB/mad: cap RMPP reassembly window size Jason Gunthorpe
2026-06-03 18:20 ` Michael Bommarito
2026-06-03 18:41 ` Jason Gunthorpe
2026-06-06 20:01 ` [PATCH v3] IB/mad: drop unmatched RMPP responses before reassembly Michael Bommarito
2026-06-29 12:11 ` Leon Romanovsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260520154715.1457495-1-michael.bommarito@gmail.com \
--to=michael.bommarito@gmail.com \
--cc=jgg@nvidia.com \
--cc=kees@kernel.org \
--cc=leonro@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=ohartoov@nvidia.com \
--cc=rpearsonhpe@gmail.com \
--cc=shefty@nvidia.com \
--cc=stable@vger.kernel.org \
--cc=vdumitrescu@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®