From: Honggang LI <honggangli@163.com>
To: Michael Gur <michaelgur@nvidia.com>
Cc: jinpu.wang@ionos.com, danil.kipnis@cloud.ionos.com, jgg@ziepe.ca,
leon@kernel.org, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] RDMA/rtrs: client: Fix clt_path::max_pages_per_mr calculation
Date: Wed, 24 Dec 2025 10:11:12 +0800 [thread overview]
Message-ID: <aUtLwLfNVGEH6lEI@fedora> (raw)
In-Reply-To: <eb0d0439-c09b-4c10-be5d-a338ede83742@nvidia.com>
On Tue, Dec 23, 2025 at 04:08:19PM +0200, Michael Gur wrote:
> Subject: Re: [PATCH] RDMA/rtrs: client: Fix clt_path::max_pages_per_mr
> calculation
> From: Michael Gur <michaelgur@nvidia.com>
> Date: Tue, 23 Dec 2025 16:08:19 +0200
>
>
> On 12/23/2025 5:43 AM, Honggang LI wrote:
> > If the low two bytes of ib_dev::attrs::max_mr_size are zeros, the `min3`
> > function will set clt_path::max_pages_per_mr to zero.
>
> Can't see how if the low two bytes of max_mr_size are zero it would cause
> the local variable max_pages_per_mr to zero.
> The more probable cause is that max_mr_size bits in the range
> [mr_page_shift+31:mr_page_shift] are zero. Since that's what's left after
> division and cast to u32.
Yes, you are right. The irdma support max_mr_size is 0x200000000000.
[mr_page_shift+31:mr_page_shift], a.k.a [43,12] are zeros.
> This means you are working on a device supporting more pages_per_mr than can
> fit in a u32.
>
> > - min3(clt_path->max_pages_per_mr, (u32)max_pages_per_mr,
> > + min(min_not_zero(clt_path->max_pages_per_mr, (u32)max_pages_per_mr),
>
> This still fixes the issue, but for readability, if max_pages_per_mr is
> larger than U32_MAX, I'd set it to be U32_MAX.
I will set it to U32_MAX as you suggested.
thanks
prev parent reply other threads:[~2025-12-24 2:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-23 3:43 [PATCH] RDMA/rtrs: client: Fix clt_path::max_pages_per_mr calculation Honggang LI
2025-12-23 14:08 ` Michael Gur
2025-12-24 2:11 ` Honggang LI [this message]
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=aUtLwLfNVGEH6lEI@fedora \
--to=honggangli@163.com \
--cc=danil.kipnis@cloud.ionos.com \
--cc=jgg@ziepe.ca \
--cc=jinpu.wang@ionos.com \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=michaelgur@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.