From: Jason Gunthorpe <jgg@nvidia.com>
To: Bob Pearson <rpearsonhpe@gmail.com>
Cc: edwards@nvidia.com, leon@kernel.org, zyjzyj2000@gmail.com,
linux-rdma@vger.kernel.org
Subject: Re: [PATCH for-rdma-core v2] pyverbs: Fix wrong rkey in test_qp_ex_rc_bind_mw
Date: Mon, 4 Jul 2022 10:24:50 -0300 [thread overview]
Message-ID: <20220704132450.GA1420265@nvidia.com> (raw)
In-Reply-To: <20220519155810.28803-1-rpearsonhpe@gmail.com>
On Thu, May 19, 2022 at 10:58:11AM -0500, Bob Pearson wrote:
> The current test_qp_ex_rc_bind_mw in tests/test_qpex.py uses an incorrect
> value for the new_rkey based on the old mr.rkey. This patch fixes that
> behavior by basing the new rkey on the old mw.rkey instead.
>
> Before this patch the test will fail for the rxe driver about 1 in 256
> tries since randomly that is the freguency of new_rkeys which have the
> same 8 bit key portion as the current mw which is not allowed. With
> this patch those errors do not occur.
While this patch seems correct, I don't understand these remarks.
IBA says:
After the bind operation completes, the R_Key must consist of the 24
bit index associated with the Type 2 Memory Window and the 8 bit key
supplied by the Con- sumer in the Post Send Bind Memory Window Work
Request.
Meaning the bind should only be processing the lower variant bits in
the first place, and there should be no condition where the bind could
fail since all varient bits are always legal.
Bind does not allow changing the upper fixed bit - only allocation can
change those. So if rxe kernel side is changing the upper bits it is
also buggy. IMHO it would be appropriate to fail the operation if
given rkey has unmatched upper bits.
Jason
next prev parent reply other threads:[~2022-07-04 13:31 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-19 15:58 [PATCH for-rdma-core v2] pyverbs: Fix wrong rkey in test_qp_ex_rc_bind_mw Bob Pearson
2022-07-04 13:24 ` Jason Gunthorpe [this message]
2022-07-14 20:20 ` Bob Pearson
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=20220704132450.GA1420265@nvidia.com \
--to=jgg@nvidia.com \
--cc=edwards@nvidia.com \
--cc=leon@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=rpearsonhpe@gmail.com \
--cc=zyjzyj2000@gmail.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;
as well as URLs for NNTP newsgroup(s).