Received: by 10.213.65.68 with SMTP id h4csp541269imn; Tue, 20 Mar 2018 09:10:54 -0700 (PDT) X-Google-Smtp-Source: AG47ELtxruK2S5lARc44WCoAHn6DF9lTgRKg9alhJOKirWCkITySmn3TycgnLivnsqmu+jdon3rj X-Received: by 10.98.246.16 with SMTP id x16mr14047884pfh.81.1521562254195; Tue, 20 Mar 2018 09:10:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521562254; cv=none; d=google.com; s=arc-20160816; b=UdBkxtLgxVpiaQNb/rcmQ9mLu5C/D6ASEnIMp3yadmgRVSkMe1Q4YBlLzJYlzPgxET GMxDsxxGyadtPONR7U8rmGWNAvgPim8uvCVPAPWYM1XOvSWzPvDVLrwPyajmhpzg/LQV mZlH4oe4g4kHn5TdZyLzcy77KgbfuKyrHHnXXZkP1VgMufmcJflnRZ5jX9bNKcZOPRho zhmmcplPd3t908QQYz+BuqEXSfbXb7wiiwHqKOWS6GcWRBtD7SSk+NjGEroWMvghDVCc mHAsmaS7CyePixQo7D/0IDGALWY2Vyd12wmBy7Gcb+kkX2dRt58u8wfwSR0Ks4tFrb9l daIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dmarc-filter :dkim-signature:dkim-signature:arc-authentication-results; bh=IjoMaGKryHBh8DceXeWxZHEAzkCmRmXx3R8KGR786a8=; b=EI9jeKoycysWgNo7NXeu1ZizaUseRx/8YE/BCSD5zTlRNhLacymB/Wi/ZVQmj3nh6v fiG7/rnLTho8Xgp9orqK0FVGfoe+5iLXXwLmTMUyd1tUAnVEgrmJOQESFyoZbB9jRA6f 36KQScsTdMgGg69xzzcxRiQMX4hl/nYNYIeLpts0sVhcYjFt1RlAKgbiA5KckVtAW5dH LB4V5hJuo1hmAHM3o/WFvEgXO0mTkQMjyAlXBPgskZtDWhvz78lsgN52t/oRGiiBCg0F CkPTKB+zm8AEGq+mspuYnTsh2apz9P+L13/v97sweYZ+/RBk8fMygUymhRpzRpEDLuON dyJA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=n2jC/8de; dkim=pass header.i=@codeaurora.org header.s=default header.b=n2jC/8de; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x14si1370627pgq.168.2018.03.20.09.10.30; Tue, 20 Mar 2018 09:10:54 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=n2jC/8de; dkim=pass header.i=@codeaurora.org header.s=default header.b=n2jC/8de; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751594AbeCTQJE (ORCPT + 99 others); Tue, 20 Mar 2018 12:09:04 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:58604 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750991AbeCTQJC (ORCPT ); Tue, 20 Mar 2018 12:09:02 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id AC91F60271; Tue, 20 Mar 2018 16:09:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1521562141; bh=FoQEBLbSe5tdEAZcoXpC8u8uZPU7iWx8gy6foP6x24s=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=n2jC/8deRYVq6J22/rqqKE7HVZtgaKoshW44H+F54P2PNDSWwn2zFe0sapnrrrp1V Bh1JHhjh4RCWgMiie6VyjZh4BN9WvV0eVJnhaCCUUNuntbW/fJIbNPHFEvaMmiYuev vgQSmCxiG9xXosuOpltzRffCQbuuZ5rgC1U/gPKg= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from [10.177.68.48] (pat_11.qualcomm.com [192.35.156.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: okaya@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 74A26607EB; Tue, 20 Mar 2018 16:09:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1521562141; bh=FoQEBLbSe5tdEAZcoXpC8u8uZPU7iWx8gy6foP6x24s=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=n2jC/8deRYVq6J22/rqqKE7HVZtgaKoshW44H+F54P2PNDSWwn2zFe0sapnrrrp1V Bh1JHhjh4RCWgMiie6VyjZh4BN9WvV0eVJnhaCCUUNuntbW/fJIbNPHFEvaMmiYuev vgQSmCxiG9xXosuOpltzRffCQbuuZ5rgC1U/gPKg= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 74A26607EB Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=okaya@codeaurora.org Subject: Re: [PATCH v4 5/6] IB/nes: Eliminate duplicate barriers on weakly-ordered archs To: Jason Gunthorpe Cc: linux-rdma@vger.kernel.org, timur@codeaurora.org, sulrich@codeaurora.org, linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Faisal Latif , Doug Ledford , linux-kernel@vger.kernel.org References: <1521514068-8856-1-git-send-email-okaya@codeaurora.org> <1521514068-8856-6-git-send-email-okaya@codeaurora.org> <20180320145413.GH19744@ziepe.ca> <3b96019a-2b3b-374a-453e-0553fb04c0a7@codeaurora.org> <20180320160151.GM19744@ziepe.ca> From: Sinan Kaya Message-ID: <77565861-7697-699f-c876-adf36db9ab5f@codeaurora.org> Date: Tue, 20 Mar 2018 11:08:59 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180320160151.GM19744@ziepe.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/20/2018 11:01 AM, Jason Gunthorpe wrote: > On Tue, Mar 20, 2018 at 10:23:16AM -0500, Sinan Kaya wrote: >> On 3/20/2018 9:54 AM, Jason Gunthorpe wrote: >>> On Mon, Mar 19, 2018 at 10:47:47PM -0400, Sinan Kaya wrote: >>>> Code includes barrier() followed by writel(). writel() already has a >>>> barrier on some architectures like arm64. >>>> >>>> This ends up CPU observing two barriers back to back before executing the >>>> register write. >>>> >>>> Create a new wrapper function with relaxed write operator. Use the new >>>> wrapper when a write is following a barrier(). >>>> >>>> Signed-off-by: Sinan Kaya >>>> drivers/infiniband/hw/nes/nes.h | 5 +++++ >>>> drivers/infiniband/hw/nes/nes_hw.c | 21 ++++++++++++++------- >>>> drivers/infiniband/hw/nes/nes_mgt.c | 15 ++++++++++----- >>>> drivers/infiniband/hw/nes/nes_nic.c | 2 +- >>>> drivers/infiniband/hw/nes/nes_utils.c | 3 ++- >>>> drivers/infiniband/hw/nes/nes_verbs.c | 5 +++-- >>>> 6 files changed, 35 insertions(+), 16 deletions(-) >>>> >>>> diff --git a/drivers/infiniband/hw/nes/nes.h b/drivers/infiniband/hw/nes/nes.h >>>> index 00c27291..85e007d 100644 >>>> +++ b/drivers/infiniband/hw/nes/nes.h >>>> @@ -387,6 +387,11 @@ static inline void nes_write_indexed(struct nes_device *nesdev, u32 reg_index, u >>>> spin_unlock_irqrestore(&nesdev->indexed_regs_lock, flags); >>>> } >>>> >>>> +static inline void nes_write32_relaxed(void __iomem *addr, u32 val) >>>> +{ >>>> + writel_relaxed(val, addr); >>>> +} >>> >>> This wrapper is pointless, let us not add more.. >>> >>>> static inline void nes_write32(void __iomem *addr, u32 val) >>>> { >>>> writel(val, addr); >>>> diff --git a/drivers/infiniband/hw/nes/nes_hw.c b/drivers/infiniband/hw/nes/nes_hw.c >>>> index 18a7de1..568e17d 100644 >>>> +++ b/drivers/infiniband/hw/nes/nes_hw.c >>>> @@ -1257,7 +1257,8 @@ int nes_destroy_cqp(struct nes_device *nesdev) >>>> >>>> barrier(); >>>> /* Ring doorbell (5 WQEs) */ >>>> - nes_write32(nesdev->regs+NES_WQE_ALLOC, 0x05800000 | nesdev->cqp.qp_id); >>>> + nes_write32_relaxed(nesdev->regs+NES_WQE_ALLOC, >>>> + 0x05800000 | nesdev->cqp.qp_id); >>> >>> barrier() is not strong enough to order writel, so this doesn't seem >>> right? >>> >>> It is probably noteven strong enough for what this driver thinks it is >>> doing.. This driver is essentially dead and broken, probably just >>> don't change it. >> >> Just for the sake of other changes in netdev directory and my education... >> >> barrier() on ARM is a wmb(). It should be a compiler barrier on intel. >> >> You are saying barrier() should have been a wmb(), right? > > Yes, that is my understanding.. barrier() is supposed to be a very > weak barrier that just ensures the CPU is locally consistent with > itself. It doesn't say anything about DMA access, or SMP cases. > > I don't think it is supposed to order anything related to > writel_relaxed() > >> I have gone through similar exercise on netdev directory and changed >> >> barrier() >> writel() >> >> to >> >> barrier() >> writel_relaxed() >> >> Do you see any problem with this? > > Seems dangerous as a mechanical change to me, it really depends on why > the driver author put barrier() there. OK. I'll drop those changes. > > In this case, I strongly suspect nes really intended to say wmb() Should I change barrier() to wmb() or leave it alone? I have no idea if nes is actively being maintained or if it is EOL. > > Jason > -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.