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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 208DEC433EF for ; Sat, 16 Apr 2022 02:14:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230072AbiDPCP5 (ORCPT ); Fri, 15 Apr 2022 22:15:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36706 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229627AbiDPCOL (ORCPT ); Fri, 15 Apr 2022 22:14:11 -0400 Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 219AADD95B for ; Fri, 15 Apr 2022 19:11:13 -0700 (PDT) Received: from dggpeml500022.china.huawei.com (unknown [172.30.72.54]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4KgGr81rrGz1HBy3; Sat, 16 Apr 2022 10:10:32 +0800 (CST) Received: from dggpeml500017.china.huawei.com (7.185.36.243) by dggpeml500022.china.huawei.com (7.185.36.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Sat, 16 Apr 2022 10:11:11 +0800 Received: from [10.40.238.78] (10.40.238.78) by dggpeml500017.china.huawei.com (7.185.36.243) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Sat, 16 Apr 2022 10:11:11 +0800 Subject: Re: [PATCH for-next 2/2] RDMA/hns: Add NOP operation for sending WR To: Jason Gunthorpe References: <20220407131403.26040-1-liangwenpeng@huawei.com> <20220407131403.26040-3-liangwenpeng@huawei.com> <20220407132012.GL2120790@nvidia.com> CC: , , From: Wenpeng Liang Message-ID: Date: Sat, 16 Apr 2022 10:11:10 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20220407132012.GL2120790@nvidia.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.40.238.78] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To dggpeml500017.china.huawei.com (7.185.36.243) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org On 2022/4/7 21:20, Jason Gunthorpe wrote: > On Thu, Apr 07, 2022 at 09:14:03PM +0800, Wenpeng Liang wrote: >> From: Yangyang Li >> >> The NOP operation is a no-op, mainly used in scenarios where SQWQE requires >> page alignment or WQE size alignment. Each NOP WR consumes one SQWQE, but >> the hardware does not operate and directly generates a CQE. The IB >> specification does not specify this type of WR. >> >> Signed-off-by: Yangyang Li >> Signed-off-by: Wenpeng Liang >> --- >> drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 9 +++++++++ >> drivers/infiniband/hw/hns/hns_roce_hw_v2.h | 9 +++++++++ >> 2 files changed, 18 insertions(+) > > Where is it used? > This function has a precondition. The driver needs to provide two interfaces to the user, one interface is used to fill the wqe, and the other is used to ring the doorbell. If the content of the wqe is repeated, then the user does not need to fill this wqe again but directly rings the doorbell. If the user's wqe used to complete the specified work request does not fill the send queue, then the user can fill the remaining wqe in the send queue as a NOP operation. This feature requires some cooperating code and does not meet the upstream conditions. Therefore, I will revoke this patch. Thanks, Wenpeng > Jason > . >