[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <afcdcbdb-5caa-6ea3-d3ed-d26237f0968f@codeaurora.org>
Date: Tue, 27 Mar 2018 18:35:34 -0400
From: Sinan Kaya <okaya@...eaurora.org>
To: Alexander Duyck <alexander.duyck@...il.com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc: Arnd Bergmann <arnd@...db.de>, Jason Gunthorpe <jgg@...pe.ca>,
David Laight <David.Laight@...lab.com>,
Oliver <oohall@...il.com>,
"open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)"
<linuxppc-dev@...ts.ozlabs.org>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
Will Deacon <will.deacon@....com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: RFC on writel and writel_relaxed
On 3/27/2018 5:54 PM, Alexander Duyck wrote:
> I view the wmb() + writel_relaxed() as more of a driver owning and
> handling this itself. Besides in the Intel Ethernet driver case it is
> better performance as our wmb() placement for us also provides a
> secondary barrier so we don't need to add a separate smp_wmb() to deal
> with a potential race we have with the Tx cleanup.
Thanks for the reminder.
I forgot about the double barrier optimization. wmb() + writel_relaxed()
seems to be the best option for Intel network drivers at this moment.
Otherwise, we'll have to remove wmb() and throw in smp barriers there
like you mentioned.
I'll leave the changes in the Intel drivers alone.
--
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.
Powered by blists - more mailing lists