All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sinan Kaya <okaya@codeaurora.org>
To: Steve Wise <swise@opengridcomputing.com>,
	netdev@vger.kernel.org, timur@codeaurora.org,
	sulrich@codeaurora.org
Cc: linux-arm-msm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	'Steve Wise' <swise@chelsio.com>,
	'Doug Ledford' <dledford@redhat.com>,
	'Jason Gunthorpe' <jgg@ziepe.ca>,
	linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org,
	'Michael Werner' <werner@chelsio.com>,
	'Casey Leedom' <leedom@chelsio.com>
Subject: Re: [PATCH v3 18/18] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs
Date: Fri, 16 Mar 2018 23:40:50 -0400	[thread overview]
Message-ID: <740c7d45-450e-c9b3-ceed-7bc7fcefbc5a@codeaurora.org> (raw)
In-Reply-To: <004501d3bd7b$505e70f0$f11b52d0$@opengridcomputing.com>

On 3/16/2018 7:05 PM, Steve Wise wrote:
>>
>> 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 <okaya@codeaurora.org>
>>>
>>> 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?
> 

I found this article: https://lwn.net/Articles/698014/#PowerPC%20Implementation

Apparently, this issue was discussed at a conference in 2015.

Based on how I read this article, writel() and writel_relaxed() behave exactly
the same on PowerPC because the barrier is enforced by the time code is leaving
a critical section not during MMIO execution.

I also see that __raw_writel() is being heavily used in drivers directory.

https://elixir.bootlin.com/linux/latest/ident/__raw_writel

I'll change writel_relaxed() with __raw_writel() in the series like you suggested
and also look at your other comments.

This seems to be the current norm.

> 
>>
>> >From API perspective both __raw_writeX() and writeX_relaxed() are
>> correct.
>> It is just PowerPC doesn't seem the follow the definition yet.
> 
> 
> 
> 


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

WARNING: multiple messages have this Message-ID (diff)
From: okaya@codeaurora.org (Sinan Kaya)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 18/18] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs
Date: Fri, 16 Mar 2018 23:40:50 -0400	[thread overview]
Message-ID: <740c7d45-450e-c9b3-ceed-7bc7fcefbc5a@codeaurora.org> (raw)
In-Reply-To: <004501d3bd7b$505e70f0$f11b52d0$@opengridcomputing.com>

On 3/16/2018 7:05 PM, Steve Wise wrote:
>>
>> 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 <okaya@codeaurora.org>
>>>
>>> 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?
> 

I found this article: https://lwn.net/Articles/698014/#PowerPC%20Implementation

Apparently, this issue was discussed at a conference in 2015.

Based on how I read this article, writel() and writel_relaxed() behave exactly
the same on PowerPC because the barrier is enforced by the time code is leaving
a critical section not during MMIO execution.

I also see that __raw_writel() is being heavily used in drivers directory.

https://elixir.bootlin.com/linux/latest/ident/__raw_writel

I'll change writel_relaxed() with __raw_writel() in the series like you suggested
and also look at your other comments.

This seems to be the current norm.

> 
>>
>> >From API perspective both __raw_writeX() and writeX_relaxed() are
>> correct.
>> It is just PowerPC doesn't seem the follow the definition yet.
> 
> 
> 
> 


-- 
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-17  3:40 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-16 16:16 [PATCH v3 00/18] Eliminate duplicate barriers on weakly-ordered archs Sinan Kaya
2018-03-16 16:16 ` Sinan Kaya
2018-03-16 16:16 ` [Intel-wired-lan] [PATCH v3 01/18] i40e/i40evf: " Sinan Kaya
2018-03-16 16:16   ` Sinan Kaya
2018-03-16 16:16   ` Sinan Kaya
2018-03-16 16:16 ` [Intel-wired-lan] [PATCH v3 02/18] ixgbe: eliminate " Sinan Kaya
2018-03-16 16:16   ` Sinan Kaya
2018-03-16 16:16   ` Sinan Kaya
2018-03-16 16:16 ` [Intel-wired-lan] [PATCH v3 03/18] igbvf: " Sinan Kaya
2018-03-16 16:16   ` Sinan Kaya
2018-03-16 16:16   ` Sinan Kaya
2018-03-16 16:16 ` [Intel-wired-lan] [PATCH v3 04/18] igb: " Sinan Kaya
2018-03-16 16:16   ` Sinan Kaya
2018-03-16 16:16   ` Sinan Kaya
2018-03-16 16:16 ` [Intel-wired-lan] [PATCH v3 05/18] ixgbevf: keep writel() closer to wmb() Sinan Kaya
2018-03-16 16:16   ` Sinan Kaya
2018-03-16 16:16   ` Sinan Kaya
2018-03-16 16:16 ` [Intel-wired-lan] [PATCH v3 06/18] ixgbevf: eliminate duplicate barriers on weakly-ordered archs Sinan Kaya
2018-03-16 16:16   ` Sinan Kaya
2018-03-16 16:16   ` Sinan Kaya
2018-03-16 16:16 ` [PATCH v3 07/18] drivers: net: cxgb: Eliminate " Sinan Kaya
2018-03-16 16:16   ` Sinan Kaya
2018-03-16 16:16 ` [PATCH v3 08/18] scsi: hpsa: " Sinan Kaya
2018-03-16 16:16   ` Sinan Kaya
2018-03-16 16:16 ` [Intel-wired-lan] [PATCH v3 09/18] fm10k: " Sinan Kaya
2018-03-16 16:16   ` Sinan Kaya
2018-03-16 16:16   ` Sinan Kaya
2018-03-16 16:30   ` [Intel-wired-lan] " Alexander Duyck
2018-03-16 16:30     ` Alexander Duyck
2018-03-16 16:30     ` Alexander Duyck
2018-03-16 16:33     ` Sinan Kaya
2018-03-16 16:33       ` Sinan Kaya
2018-03-16 16:33       ` Sinan Kaya
2018-03-16 16:16 ` [PATCH v3 10/18] net: qla3xxx: " Sinan Kaya
2018-03-16 16:16   ` Sinan Kaya
2018-03-16 16:16 ` [PATCH v3 11/18] qlcnic: " Sinan Kaya
2018-03-16 16:16   ` Sinan Kaya
2018-03-19 20:10   ` Chopra, Manish
2018-03-19 20:10     ` Chopra, Manish
2018-03-16 16:16 ` [PATCH v3 12/18] bnx2x: " Sinan Kaya
2018-03-16 16:16   ` Sinan Kaya
2018-03-16 16:16 ` [PATCH v3 13/18] net: cxgb4/cxgb4vf: " Sinan Kaya
2018-03-16 16:16   ` Sinan Kaya
2018-03-16 16:16 ` [PATCH v3 14/18] net: cxgb3: " Sinan Kaya
2018-03-16 16:16   ` Sinan Kaya
2018-03-16 16:16 ` [PATCH v3 15/18] RDMA/bnxt_re: " Sinan Kaya
2018-03-16 16:16   ` Sinan Kaya
2018-03-16 16:16 ` [PATCH v3 16/18] IB/mlx4: " Sinan Kaya
2018-03-16 16:16   ` Sinan Kaya
2018-03-16 16:16 ` [PATCH v3 17/18] RDMA/i40iw: " Sinan Kaya
2018-03-16 16:16   ` Sinan Kaya
2018-03-16 16:16 ` [PATCH v3 18/18] infiniband: cxgb4: " Sinan Kaya
2018-03-16 16:16   ` Sinan Kaya
2018-03-16 21:05   ` Steve Wise
2018-03-16 21:05     ` Steve Wise
2018-03-16 21:05     ` Steve Wise
2018-03-16 21:46     ` Sinan Kaya
2018-03-16 21:46       ` Sinan Kaya
2018-03-16 23:05       ` Steve Wise
2018-03-16 23:05         ` Steve Wise
2018-03-16 23:05         ` Steve Wise
2018-03-17  3:40         ` Sinan Kaya [this message]
2018-03-17  3:40           ` Sinan Kaya
2018-03-17  4:03           ` Sinan Kaya
2018-03-17  4:03             ` Sinan Kaya
2018-03-17  4:25             ` Sinan Kaya
2018-03-17  4:25               ` Sinan Kaya
2018-03-17  4:30               ` Timur Tabi
2018-03-17  4:30                 ` Timur Tabi
2018-03-17 13:23               ` Steve Wise
2018-03-17 13:23                 ` Steve Wise
2018-03-17 13:23                 ` Steve Wise
2018-03-17 13:27               ` David Miller
2018-03-17 13:27                 ` David Miller
2018-03-17 15:05               ` Jason Gunthorpe
2018-03-17 15:05                 ` Jason Gunthorpe
2018-03-17 18:30                 ` Sinan Kaya
2018-03-17 18:30                   ` Sinan Kaya
2018-03-19  1:48                   ` Jason Gunthorpe
2018-03-19  1:48                     ` Jason Gunthorpe
2018-03-16 22:13     ` Jason Gunthorpe
2018-03-16 22:13       ` Jason Gunthorpe
2018-03-16 23:04       ` Steve Wise
2018-03-16 23:04         ` Steve Wise
2018-03-16 23:04         ` Steve Wise
2018-03-17  4:08         ` Timur Tabi
2018-03-17  4:08           ` Timur Tabi

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=740c7d45-450e-c9b3-ceed-7bc7fcefbc5a@codeaurora.org \
    --to=okaya@codeaurora.org \
    --cc=dledford@redhat.com \
    --cc=jgg@ziepe.ca \
    --cc=leedom@chelsio.com \
    --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=netdev@vger.kernel.org \
    --cc=sulrich@codeaurora.org \
    --cc=swise@chelsio.com \
    --cc=swise@opengridcomputing.com \
    --cc=timur@codeaurora.org \
    --cc=werner@chelsio.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.