Re: [PATCH v2] IB/mad: cap RMPP reassembly window size

[Jason Gunthorpe <jgg@nvidia.com>]

On Wed, May 20, 2026 at 11:47:15AM -0400, Michael Bommarito wrote:
> 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.

Why do you think it is OK to only search back 64? Where do these
numbers come from?

Is this a real issue?  It looks to me like all this code is gated by
IB_USER_MAD_USER_RMPP and no in-kernel user makes use of RMPP.

Use of RMPP in userspace is extremely rare and requires privilege to
activate. If userspace opts into it then and only then would there be
a performance issue.

So I don't see why we should be changing this and risking regressions
with the window reduction?

Jason