From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-177.mta0.migadu.com (out-177.mta0.migadu.com [91.218.175.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3529D33032E for ; Sat, 21 Feb 2026 10:28:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771669706; cv=none; b=dB8C0p+LKRXO1T1+jC48sswaIiYnweof42l0vhWvGIG6nMluOKjo95F24gfWHxCnX/rs8fBHEdTbQyejIOFsJZXNuyxYnYX9Btt1MIP9rhIsMmwUfhAYJttugWuI/b4DcCCyYTsEMsbGMJeG3ajvO2yTUjo9kz2y3tYq1lFm3cg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771669706; c=relaxed/simple; bh=/s+SEEiPMc0bkUJXL4uO6bDigv3PZMyOm7SfZ+0ZaQo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ATDf72P5WOXUXS9SUPS7/fNo9ncoJ0fM3mzyJWdUpllatddqOiaVI1jN3WooMErRaee5+cdVGerangzXQ+luN7mpweInCAmQC6vgrhqi6WAuIfrMOUMiepYxDDFp2XQEhIi3SMwgtrLjOyv5HRUiyTA/25bPUwFm1BGc6xHEikY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=Szn+TSDn; arc=none smtp.client-ip=91.218.175.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="Szn+TSDn" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1771669693; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=OE/jhhKZszyhcMtiWaepIH+sIXtYc36Quc/erjuILb8=; b=Szn+TSDn3HARqyBg+o+p32Z+IAXf3ogTafU+xfeX1b/uH4OWg/+hI2aOOFcMs0w7Du0cYy qSBNwx/8JkvvoDeAMMu7Woeg/ezaj9tV65Be4HiwJ3U2oi3mJN64dXQKcEJqm9LiQmND6v eIoHiZ4naLW4sFgHsLjlfi0uPCTL854= Date: Sat, 21 Feb 2026 02:28:09 -0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH] RDMA/rxe: Generate async error for r_key violations To: Evan Green , Zhu Yanjun Cc: Wei Lin Guay , Jason Gunthorpe , Leon Romanovsky , "linux-kernel@vger.kernel.org" , "linux-rdma@vger.kernel.org" References: <20260212164355.3585961-1-evgreen@meta.com> <9264c8bf-e3cd-46db-b1a9-63a556ecb1d4@linux.dev> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Zhu Yanjun In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT 在 2026/2/20 9:59, Evan Green 写道: > Hi Yanjun, > > > On 2/12/26, 11:48 AM, "yanjun.zhu" > wrote: >> >> 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." > Apologies for the delayed response, I'm having an awful time setting up a mail client with proper formatting. > > Sure, I'll add this and send a v2. > >> >> 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. > 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. 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 > >> >> Thanks, >> Reviewed-by: Zhu Yanjun > > Thank you! > -Evan > > > > -- Best Regards, Yanjun.Zhu