Received: by 10.213.65.68 with SMTP id h4csp536318imn; Tue, 20 Mar 2018 09:04:50 -0700 (PDT) X-Google-Smtp-Source: AG47ELtVp8gxR6ybX1F84xpqfAG54v9UHAqQ4lIl+lpoen3cx2YekDdPslOgScsrpThKJV+9I74k X-Received: by 10.101.78.15 with SMTP id r15mr7086210pgt.283.1521561890665; Tue, 20 Mar 2018 09:04:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521561890; cv=none; d=google.com; s=arc-20160816; b=eX4B6zJxiBU9XUT6iMASitwTZ6qY5cpFO/x2W5zNurtoqNVPO69tmpJuYOSOHK50Fj RPRy25sQ0SCewb7y9ZpPoM+Av47cZxgJVe7r4KsstgyotX9DZEuel/qF+CJDPdPuQKuo 4UtIAw9pKyjx+cI9JL8WGEfFcwNKLZkj4zxGyRQbFB7DmY48KQJH6hgSc0BoWnAtXwH8 zcJJdIA9E6Y1m1bWz4Ajz7HNeJzqIvb4gKSq8SpnxLIrLpzrDr0j8P+yrsXR6f9l1w00 YGcDBwSc5j1sxRhM7mMKE85GIEsIvydxG94SgXFBcpRD5DaE85UX473Fe/DISS/4BHXt pHhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=MksL5nw6+GLKKiJcGfQPXhz5/puwyNH84AmJHQUrawM=; b=cVshtcdS4yikx/Qcc/vXqrhrsXsXKtx5Sb+3a4ccQI+sS3C1YwJJvNu/EnK6qHo1gb c4a0Gt/2lK3CmBHsinbGWsoDnCOnDWYSACwwolI9prmYnjZpx6jadbKSs6RHsn19iP8c Cj47UfK+C2z5hOyJ3Xwl7SphFuPKaZtNEDUL/saA7IYhpSplG7tO7BhM6LvbuVEDeK7M a2TMyCQD9AVhG1VXA+xX5Nd8+QkUjT59HLct6MXhNqM2yU0MCmZsgpEjGL01R4D5cGW6 0OdWjI2WnUJ+utoNAzR3eHzT6BlrcJP/DhC1NZTnOdYWTFaJElhT5mfYH+Gnfss2k6Si QpdA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ziepe.ca header.s=google header.b=TQpOso6q; 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 d4si1316744pgv.560.2018.03.20.09.04.24; Tue, 20 Mar 2018 09:04:50 -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=@ziepe.ca header.s=google header.b=TQpOso6q; 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 S1751774AbeCTQCj (ORCPT + 99 others); Tue, 20 Mar 2018 12:02:39 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:52463 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751411AbeCTQCh (ORCPT ); Tue, 20 Mar 2018 12:02:37 -0400 Received: by mail-wm0-f68.google.com with SMTP id l9so4496071wmh.2 for ; Tue, 20 Mar 2018 09:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=MksL5nw6+GLKKiJcGfQPXhz5/puwyNH84AmJHQUrawM=; b=TQpOso6qQX2OIbdGl0OdVaLtDeXhJa1L2ajQEveK3dpeth5COUHcv5SiN8t7tNIcvk lRmk+l2Hx81u9ZxhJDRrTLa46dBtpOUvuYq4VB1+lRQ+fXTLqP7D4adxMl3GHZlnFVyq pOGn9wEdnttDdcIbb2KA3ZZCsrg+lqcXo7+c7JrqVZrpWlVPSpLLGsY0AtJaOISIpyN6 xv1v4xsDhio39J+bk7fJNZQCPJZC2Vx0AeOSZ4Vb1wJ2NXtc3NJHEJJlTCLWwjxx0jJu uqda6luZ9x+7K1hPAMY0hil54ELjs1BeJ+ttiMHIRDg9iVyNDeU4+NEm/ycpVwLiC7cv QTXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=MksL5nw6+GLKKiJcGfQPXhz5/puwyNH84AmJHQUrawM=; b=th8hDwgygJxDwj6YdCGAGXiFuBzcTg2qQW/ZkCLThqR2v01dW4DMsD3eqoEL1AgisW /ohFFuSIThstECs0K8M2MiSuLiDu17cX0ShEES7DbQepT48uM1ehIr02juF/m7j3Xcef QkCBxC3I/tuZVjDKXh9FADEj6v6DeqD4SOn8/4b2Wzk5GAgEhgfbE8FCwoE4TfaLCBgA eAZA5UfnmkSmGNC+ucEq5JvmOeJ/L7bQ1dKGioiMPdqCWW1n2JLE3cMzNL1JE4iKpgds jImZn/4QaRS3y7fOO2+ZRLOQidle77/nEPrWMVI4yeD6StPvWxmBEeNyJsehILnviPv+ uQZA== X-Gm-Message-State: AElRT7FdMlcb4uGEwJokJNsLIeAOnokJg2Ioq8V6rh291re4FiQGRRxJ kAm/VOICymdlLkpjDqbZikWEdg== X-Received: by 10.28.203.15 with SMTP id b15mr111320wmg.105.1521561755810; Tue, 20 Mar 2018 09:02:35 -0700 (PDT) Received: from ziepe.ca (S010614cc2056d97f.ed.shawcable.net. [174.3.196.123]) by smtp.gmail.com with ESMTPSA id 63sm1737856wrn.7.2018.03.20.09.02.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Mar 2018 09:02:33 -0700 (PDT) Received: from jgg by mlx.ziepe.ca with local (Exim 4.86_2) (envelope-from ) id 1eyJiX-0006ug-L4; Tue, 20 Mar 2018 10:02:29 -0600 Date: Tue, 20 Mar 2018 10:02:29 -0600 From: Jason Gunthorpe To: Sinan Kaya Cc: linux-rdma@vger.kernel.org, timur@codeaurora.org, sulrich@codeaurora.org, linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Selvin Xavier , Devesh Sharma , Somnath Kotur , Sriharsha Basavapatna , Doug Ledford , linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 1/6] RDMA/bnxt_re: Eliminate duplicate barriers on weakly-ordered archs Message-ID: <20180320160229.GN19744@ziepe.ca> References: <1521514068-8856-1-git-send-email-okaya@codeaurora.org> <1521514068-8856-2-git-send-email-okaya@codeaurora.org> <20180320144801.GE19744@ziepe.ca> <20180320152043.GK19744@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 20, 2018 at 10:30:34AM -0500, Sinan Kaya wrote: > On 3/20/2018 10:20 AM, Jason Gunthorpe wrote: > > On Tue, Mar 20, 2018 at 10:00:49AM -0500, Sinan Kaya wrote: > >> On 3/20/2018 9:48 AM, Jason Gunthorpe wrote: > >>> On Mon, Mar 19, 2018 at 10:47:43PM -0400, Sinan Kaya 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 > >>>> drivers/infiniband/hw/bnxt_re/qplib_rcfw.c | 8 ++++---- > >>>> 1 file changed, 4 insertions(+), 4 deletions(-) > >>>> > >>>> diff --git a/drivers/infiniband/hw/bnxt_re/qplib_rcfw.c b/drivers/infiniband/hw/bnxt_re/qplib_rcfw.c > >>>> index 8329ec6..4a6b981 100644 > >>>> +++ b/drivers/infiniband/hw/bnxt_re/qplib_rcfw.c > >>>> @@ -181,10 +181,10 @@ static int __send_message(struct bnxt_qplib_rcfw *rcfw, struct cmdq_base *req, > >>>> > >>>> /* ring CMDQ DB */ > >>>> wmb(); > >>>> - writel(cmdq_prod, rcfw->cmdq_bar_reg_iomem + > >>>> - rcfw->cmdq_bar_reg_prod_off); > >>>> - writel(RCFW_CMDQ_TRIG_VAL, rcfw->cmdq_bar_reg_iomem + > >>>> - rcfw->cmdq_bar_reg_trig_off); > >>>> + writel_relaxed(cmdq_prod, rcfw->cmdq_bar_reg_iomem + > >>>> + rcfw->cmdq_bar_reg_prod_off); > >>>> + writel_relaxed(RCFW_CMDQ_TRIG_VAL, rcfw->cmdq_bar_reg_iomem + > >>>> + rcfw->cmdq_bar_reg_trig_off); > >>> > >>> Woah, this may not be safe.. > >>> > >>> The definition of writel_relaxed() is that it is fully unordered, so > >>> the above two writes may change order now. Broadcom guys would have to > >>> ack if that it is OK or not for their hardware. > >>> > >>> In general this is not an OK approach for a mechanical > >>> conversion.. Only the first writel can be convereted. > >>> > >>> You need to check all your patches to make sure there are no > >>> subsequent writel's in the places touched. > >> > >> I paid special attention to this one and went to check the barriers > >> document. According to the document, writes (whether it is relaxed or not) > >> are always observed by the HW inorder with respect to each other. > > > > Oh interesting, that document got revised to make writel_relaxed less > > relaxed a few years ago, didn't know that. Thanks. > > > > However, this is still not OK, the full code is: > > > > /* ring CMDQ DB */ > > wmb(); > > writel(cmdq_prod, rcfw->cmdq_bar_reg_iomem + > > rcfw->cmdq_bar_reg_prod_off); > > writel(RCFW_CMDQ_TRIG_VAL, rcfw->cmdq_bar_reg_iomem + > > rcfw->cmdq_bar_reg_trig_off); > > done: > > spin_unlock_irqrestore(&cmdq->lock, flags); > > > > > > And the definition of _relaxed allows the writes to order outside the > > spinlock region, which is very likely to be wrong in this driver. > > > > I'm not sure adding a mmiowb() just to use a writel_relaxed is any > > sort of win though? > > I'd prefer this. > > mmiowb() on ARM64 is empty. mmiowb() guarantees that code also works for PPC too. > > I'll switch to this instead so it works for everybody. It looks like a compiler barrier on x86 so that seems fine too. Jason