Received: by 10.213.65.68 with SMTP id h4csp23358imn; Fri, 16 Mar 2018 16:07:15 -0700 (PDT) X-Google-Smtp-Source: AG47ELvLTgSFMHSc/+tZpzm76LXqrYeo7bJjREEqeAFlwuRq/V7Ot+bRbQOXFe4JcitSlOuGaGWG X-Received: by 10.99.112.92 with SMTP id a28mr2758641pgn.17.1521241635871; Fri, 16 Mar 2018 16:07:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521241635; cv=none; d=google.com; s=arc-20160816; b=w4dL2wYO7r0Uys4mqH5hb6ZO+nWhXEObXYa4xQSWxM1mGAY/+YKxGvDdFt4+wbUIB6 hJqdRpfK7wODUWqkblz53FitSo4nMG/ZmtjmwzXRa2SQSNY7+izJg1Vwg6MwaK+1p2jS h+/HPLb3FvZUN2ZBGKyK4yy8jW68v0mRWV2QMhKvWW93B7P5N61wPuftLCjMWJiI44KO yWUNy5sNtd/tlfbmx07qLilfa5iZA8px8olncJHuBITuEuINUJAT07g3XEVM+EczsBhZ kw6wNePN8mqZEuegTZHb0sfOgaD96q/U/XUtZtzlVf0RAm4JrNYcA6zO/vKCgnldFzw0 Qj5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language:thread-index :content-transfer-encoding:mime-version:message-id:date:subject :in-reply-to:references:cc:to:from:arc-authentication-results; bh=oy02RNZvqQQnREhWDjzej5R4cBjnUlSliCaL5WxI04Q=; b=Yl2QeCo2xWZyfVMcggU3i2ZhJUJ8RfFTOBTlkRnP+zgsvIXHWEbU+TP1nG4Mf7/YLm wowILE+TPhpyOGVOlsfwLo8jssrSfsz+gF975K+AJx/jQHRXK8qNd4Okq+baaN7VsEKl N17v7F1O+/bA141hdWgz0sF0DNKSH6e/6BYbfaUsUinuj0HDX3iFOCO2jEWc7zVYBY8c H27P/CL8zyvJeA6QyaNrMyerWgW6LKj66swF1jhATTvj+59iizp4hFC3llGltwmUygMg af9mM4WyZGiU2Zu3tt8uVViT+8MSott7pduMa9uYw0rO5wAscuMaJQmyvCDeFk5qzqZb 15nA== ARC-Authentication-Results: i=1; mx.google.com; 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 r4si6279382pfb.394.2018.03.16.16.07.01; Fri, 16 Mar 2018 16:07:15 -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; 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 S1752863AbeCPXFr convert rfc822-to-8bit (ORCPT + 99 others); Fri, 16 Mar 2018 19:05:47 -0400 Received: from linode.aoot.com ([69.164.194.13]:54470 "EHLO linode.aoot.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751454AbeCPXFq (ORCPT ); Fri, 16 Mar 2018 19:05:46 -0400 Received: from stevoacer (47-221-140-100.gtwncmta03.res.dyn.suddenlink.net [47.221.140.100]) by linode.aoot.com (Postfix) with ESMTP id 58D5C8326; Fri, 16 Mar 2018 18:05:45 -0500 (CDT) From: "Steve Wise" To: "'Sinan Kaya'" , , , Cc: , , "'Steve Wise'" , "'Doug Ledford'" , "'Jason Gunthorpe'" , , , "'Michael Werner'" , "'Casey Leedom'" References: <1521216991-28706-1-git-send-email-okaya@codeaurora.org> <1521216991-28706-19-git-send-email-okaya@codeaurora.org> <003601d3bd6a$783d6970$68b83c50$@opengridcomputing.com> <83387f6e-adcb-14e9-2c22-96abf9493cc6@codeaurora.org> In-Reply-To: <83387f6e-adcb-14e9-2c22-96abf9493cc6@codeaurora.org> Subject: RE: [PATCH v3 18/18] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs Date: Fri, 16 Mar 2018 18:05:44 -0500 Message-ID: <004501d3bd7b$505e70f0$f11b52d0$@opengridcomputing.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8BIT X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQE6mTD+J/QLr4bfMbM+wOAMMt4Q1AI7R6heAYll0hoCDc6xe6TXMBTg Content-Language: en-us Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > On 3/16/2018 5:05 PM, Steve Wise wrote: > >> Code includes wmb() 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. > >> > >> Since code already has an explicit barrier call, changing writel() to > >> writel_relaxed(). > >> > >> Signed-off-by: Sinan Kaya > > > > NAK - This isn't correct for PowerPC. For PowerPC, writeX_relaxed() is just > > writeX(). > > > > I was just looking at this with Chelsio developers, and they said the > > writeX() should be replaced with __raw_writeX(), not writeX_relaxed(), to > > get rid of the extra barrier for all architectures. > > OK. I can do that but isn't the problem at PowerPC adaptation? > > /* > * We don't do relaxed operations yet, at least not with this semantic > */ > #define readb_relaxed(addr) readb(addr) > #define readw_relaxed(addr) readw(addr) > #define readl_relaxed(addr) readl(addr) > #define readq_relaxed(addr) readq(addr) > #define writeb_relaxed(v, addr) writeb(v, addr) > #define writew_relaxed(v, addr) writew(v, addr) > #define writel_relaxed(v, addr) writel(v, addr) > #define writeq_relaxed(v, addr) writeq(v, addr) > > Why don't we fix the PowerPC's relaxed operators? Is that a bigger task? I don't know the answer, but perhaps the proper fix is to correctly implement these for PPC? > > >From API perspective both __raw_writeX() and writeX_relaxed() are > correct. > It is just PowerPC doesn't seem the follow the definition yet.