mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Sinan Kaya <okaya@codeaurora.org>
To: Jason Gunthorpe <jgg@ziepe.ca>
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 <selvin.xavier@broadcom.com>,
	Devesh Sharma <devesh.sharma@broadcom.com>,
	Somnath Kotur <somnath.kotur@broadcom.com>,
	Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>,
	Doug Ledford <dledford@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 1/6] RDMA/bnxt_re: Eliminate duplicate barriers on weakly-ordered archs
Date: Tue, 20 Mar 2018 10:08:16 -0500	[thread overview]
Message-ID: <3e6cfa25-6b9f-24ff-499a-6df2740b658b@codeaurora.org> (raw)
In-Reply-To: <d31c062b-5629-62b8-c291-c656e23c6f82@codeaurora.org>

On 3/20/2018 10:00 AM, 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 <okaya@codeaurora.org>
>>>  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.
> It just doesn't guarantee anything above writel_relaxed() to be observed.
> Since we already have a wmb(), this is taken care of. 
> 
> If somebody wants things to be observed after register write, there should
> have been a wmb() or mmiowb() afterwards.

Never mind, it will break some architectures. I'll only change the first one.

 (1) On some systems, I/O stores are not strongly ordered across all CPUs, and
     so for _all_ general drivers locks should be used and mmiowb() must be
     issued prior to unlocking the critical section.

 (2) If the accessor functions are used to refer to an I/O memory window with
     relaxed memory access properties, then _mandatory_ memory barriers are
     required to enforce ordering. 


> 
> 
>>
>> 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.

  reply	other threads:[~2018-03-20 15:08 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1521514068-8856-1-git-send-email-okaya@codeaurora.org>
2018-03-20  2:47 ` Sinan Kaya
2018-03-20 14:48   ` Jason Gunthorpe
2018-03-20 15:00     ` Sinan Kaya
2018-03-20 15:08       ` Sinan Kaya [this message]
2018-03-20 15:23         ` Jason Gunthorpe
2018-03-20 15:20       ` Jason Gunthorpe
2018-03-20 15:30         ` Sinan Kaya
2018-03-20 16:02           ` Jason Gunthorpe
2018-03-20  2:47 ` [PATCH v4 2/6] IB/mlx4: " Sinan Kaya
2018-03-20 14:48   ` Jason Gunthorpe
2018-03-20  2:47 ` [PATCH v4 3/6] RDMA/i40iw: " Sinan Kaya
2018-03-20 14:56   ` Jason Gunthorpe
2018-03-21 13:38   ` Shiraz Saleem
2018-03-21 20:02   ` Jason Gunthorpe
2018-03-21 21:01     ` Sinan Kaya
2018-03-20  2:47 ` [PATCH v4 4/6] infiniband: cxgb4: " Sinan Kaya
2018-03-20 14:51   ` Jason Gunthorpe
2018-03-20 15:10     ` Steve Wise
2018-03-20 15:38     ` Steve Wise
2018-03-22  6:44   ` kbuild test robot
2018-03-22 12:24     ` okaya
2018-03-22 12:48       ` okaya
2018-03-22 14:33         ` Sinan Kaya
2018-03-22 14:40         ` Steve Wise
2018-03-22 14:52           ` Sinan Kaya
2018-03-22 16:28             ` Steve Wise
2018-03-22 19:44               ` Casey Leedom
2018-03-22 20:16                 ` Jason Gunthorpe
2018-03-22 20:45                   ` Casey Leedom
2018-03-22 21:25                     ` Jason Gunthorpe
2018-03-22 21:27                     ` Sinan Kaya
2018-03-22 22:02                       ` Casey Leedom
     [not found]         ` <437ab002-b8db-24aa-583e-0e61d61aaa97@codeaurora.org>
2018-03-22 18:46           ` Jason Gunthorpe
2018-03-22 18:48         ` Jason Gunthorpe
2018-03-22 18:58           ` Sinan Kaya
2018-03-23  4:14   ` kbuild test robot
2018-03-20  2:47 ` [PATCH v4 5/6] IB/nes: " Sinan Kaya
2018-03-20 14:54   ` Jason Gunthorpe
2018-03-20 15:23     ` Sinan Kaya
2018-03-20 16:01       ` Jason Gunthorpe
2018-03-20 16:08         ` Sinan Kaya
2018-03-20 16:29           ` Jason Gunthorpe
2018-03-20  2:47 ` [PATCH v4 6/6] RDMA/qedr: eliminate duplicate barriers on weakly-ordered archs #2 Sinan Kaya
2018-03-20  7:38   ` Kalderon, Michal
2018-03-20 14:55   ` Jason Gunthorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3e6cfa25-6b9f-24ff-499a-6df2740b658b@codeaurora.org \
    --to=okaya@codeaurora.org \
    --cc=devesh.sharma@broadcom.com \
    --cc=dledford@redhat.com \
    --cc=jgg@ziepe.ca \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=selvin.xavier@broadcom.com \
    --cc=somnath.kotur@broadcom.com \
    --cc=sriharsha.basavapatna@broadcom.com \
    --cc=sulrich@codeaurora.org \
    --cc=timur@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome