From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A31BDC433E0 for ; Fri, 29 Jan 2021 05:43:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 55FCD64DFF for ; Fri, 29 Jan 2021 05:43:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229927AbhA2FnJ (ORCPT ); Fri, 29 Jan 2021 00:43:09 -0500 Received: from mail.cn.fujitsu.com ([183.91.158.132]:13621 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S229463AbhA2FnI (ORCPT ); Fri, 29 Jan 2021 00:43:08 -0500 X-IronPort-AV: E=Sophos;i="5.79,384,1602518400"; d="scan'208";a="103971683" Received: from unknown (HELO cn.fujitsu.com) ([10.167.33.5]) by heian.cn.fujitsu.com with ESMTP; 29 Jan 2021 13:42:22 +0800 Received: from G08CNEXMBPEKD06.g08.fujitsu.local (unknown [10.167.33.206]) by cn.fujitsu.com (Postfix) with ESMTP id 90D4E4CE6789; Fri, 29 Jan 2021 13:42:18 +0800 (CST) Received: from [10.167.220.69] (10.167.220.69) by G08CNEXMBPEKD06.g08.fujitsu.local (10.167.33.206) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 29 Jan 2021 13:42:18 +0800 Message-ID: <6013A038.9000903@cn.fujitsu.com> Date: Fri, 29 Jan 2021 13:42:16 +0800 From: Xiao Yang User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.2; zh-CN; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Bob Pearson CC: Leon Romanovsky , , Subject: Re: [RFC PATCH] RDMA/rxe: Export imm_data to WC when the related WR with imm_data finished on SQ References: <20210127082431.2637863-1-yangx.jy@cn.fujitsu.com> <20210127120427.GJ1053290@unreal> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.167.220.69] X-ClientProxiedBy: G08CNEXCHPEKD06.g08.fujitsu.local (10.167.33.205) To G08CNEXMBPEKD06.g08.fujitsu.local (10.167.33.206) X-yoursite-MailScanner-ID: 90D4E4CE6789.ACE16 X-yoursite-MailScanner: Found to be clean X-yoursite-MailScanner-From: yangx.jy@cn.fujitsu.com Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org On 2021/1/28 3:40, Bob Pearson wrote: > On 1/27/21 6:04 AM, Leon Romanovsky wrote: >> On Wed, Jan 27, 2021 at 04:24:31PM +0800, Xiao Yang wrote: >>> Even if we enable sq_sig_all or IBV_SEND_SIGNALED, current rxe >>> module cannot set imm_data in WC when the related WR with imm_data >>> finished on SQ. >>> >>> Signed-off-by: Xiao Yang >>> --- >>> >>> Current rxe module and other rdma modules(e.g. mlx5) only set >>> imm_data in WC when the related WR with imm_data finished on RQ. >>> I am not sure if it is a expected behavior. >> This is IBTA behavior. >> >> 5.2.11 IMMEDIATE DATA EXTENDED TRANSPORT HEADER (ImmDt) - 4 BYTES >> "Immediate Data (ImmDt) contains data that is placed in the receive >> Completion Queue Element (CQE). The ImmDt is only allowed in SEND or >> RDMA WRITE packets with Immediate Data." >> >> If I understand the spec, you shouldn't set imm_data in SQ. >> >> Thanks >> > This seems a little confused to me. wc.imm_data is set in rxe_resp.c in response to an incoming request packet that contains an IMMDT extension header. I.e. a write with immediate or send with immediate opcode from the remote end of the wire. This wc is delivered to the receive completion queue when the message is complete. It should not have anything to do with the local send work queue entries. Hi Bob, Current rdma modules(e.g softroce, mlx5) only set wc_flags to IBV_WC_WITH_IMM for the completed send work queue entries. I am not sure if it is also the IBTA behavior. Best Regards, Xiao Yang > Bob Pearson > > > . >