Re: [PATCH] RDMA/rxe: Generate async error for r_key violations
From: Zhu Yanjun
Date: Sat Feb 21 2026 - 05:28:32 EST
在 2026/2/20 9:59, Evan Green 写道:
Hi Yanjun,
> On 2/12/26, 11:48 AM, "yanjun.zhu" <yanjun.zhu@xxxxxxxxx <mailto:yanjun.zhu@xxxxxxxxx>> wrote:
Apologies for the delayed response, I'm having an awful time setting up a mail client with proper formatting.
On 2/12/26 8:43 AM, Evan Green wrote:
Table 63 of the IBTA spec lists R_Key violations as a class C
error. 9.9.3.1.3 Responder Class C Fault Behavior indicates an
affiliated asynchronous error should be generated at the responder
if the error can be associated to a QP but not a particular RX WQE.
This paragraph should be the descriptions in the commit log.
"C9-222.1.1: For an HCA responder using Reliable Connection service, for
a Class C responder side error, the error shall be reported to the requester
by generating the appropriate NAK code as specified in Table 63 Re-
sponder Error Behavior Summary on page 448. If the error can be related
to a particular QP but cannot be related to a particular WQE on that re-
ceive queue (e.g. the error occurred while executing an RDMA Write Re-
quest without immediate data), the error shall be reported to the
responder’s client as an Affiliated Asynchronous error. See Section
10.10.2.3 Asynchronous Errors on page 576 for details. If the error can be
related to a particular WQE on a given receive queue, the QP shall be
placed into the error state and the error shall be reported to the re-
sponder’s client as a Completion error. See Section 10.10.2.2 Completion
Errors on page 575."
Sure, I'll add this and send a v2.
I... can't tell, kind of? I see three places where QP_ACCESS_ERR events are generated in siw. They do look like R_Key violation scenarios, though I don’t see any any spots where SIW_WC_REM_ACCESS_ERR is produced as an error code.
In this commit, a new asynchrounous event
RESPST_ERR_RKEY_VIOLATION_EVENT is introduced and implemented based on
9.9.3.1.3. It is not a bug fix. As such, no FIXES tag.
I am fine with this. I am just wondering if this similar feature has
already been implemented in iWARP driver or not.
Thank you very much. I’ve also looked into the iWARP driver and have similar thoughts to yours. If you’re interested in working on the iWARP driver, you’re welcome to implement this feature there as well—it’s entirely up to you. I simply hope that both iWARP and RXE continue to improve over time.
Thanks,
Yanjun.Zhu
--
Thank you!
Thanks,
Reviewed-by: Zhu Yanjun <yanjun.zhu@xxxxxxxxx <mailto:yanjun.zhu@xxxxxxxxx>>
-Evan
Best Regards,
Yanjun.Zhu