Re: Fwd: Possible bug in test_mr.py

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Bob,

You're referring to the "test_mr_rereg_access" of test_mr.py, aren't you?
We need to re-sync the rkeys between the two sides, for example by calling the sync_remote_attr() after reregistering the MRs. And if that's the case, and the MR keys could change, maybe it's better to re-sync the keys between the two sides after each rereg call.

I'll push a fix - in case I misunderstood you or that's not the point you tried to make, please let me know.

Thanks,
Edward.

On 3/29/2021 7:18 AM, Bob Pearson wrote:


-------- Forwarded Message --------
Subject: Possible bug in test_mr.py
Date: Sun, 28 Mar 2021 22:52:01 -0500
From: Bob Pearson <rpearsonhpe@xxxxxxxxx>
To: Jason Gunthorpe <jgg@xxxxxxxxxx>, Zhu Yanjun <zyjzyj2000@xxxxxxxxx>, linux-rdma@xxxxxxxxxxxxxx

Testing ibv_rereg_mr() I noticed that the test uses the rkey originally assigned to the MR by ibv_reg_mr() and not
the rkey subsequently assigned after calling ibv_rereg_mr(). This matters when the original MR did not have remote
memory access and rkey was set to zero. If the rereg changes access to allow remote memory access then the rkey is set
when the verb returns. But the test code never looks again after setting up the original MRs.

In rxe setting rkey = lkey always gets the first rereg test case to pass.

bob



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux