From: Alexander Duyck <alexander.h.duyck@redhat.com>
To: Will Deacon <will.deacon@arm.com>
Cc: "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"mathieu.desnoyers@polymtl.ca" <mathieu.desnoyers@polymtl.ca>,
"peterz@infradead.org" <peterz@infradead.org>,
"benh@kernel.crashing.org" <benh@kernel.crashing.org>,
"heiko.carstens@de.ibm.com" <heiko.carstens@de.ibm.com>,
"mingo@kernel.org" <mingo@kernel.org>,
"mikey@neuling.org" <mikey@neuling.org>,
"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
"donald.c.skidmore@intel.com" <donald.c.skidmore@intel.com>,
"matthew.vick@intel.com" <matthew.vick@intel.com>,
"geert@linux-m68k.org" <geert@linux-m68k.org>,
"jeffrey.t.kirsher@intel.com" <jeffrey.t.kirsher@intel.com>,
"romieu@fr.zoreil.com" <romieu@fr.zoreil.com>,
"paulmck@linux.vnet.ibm.com" <paulmck@linux.vnet.ibm.com>,
"nic_swsd@realtek.com" <nic_>
Subject: Re: [PATCH v5 2/4] arch: Add lightweight memory barriers dma_rmb() and dma_wmb()
Date: Tue, 25 Nov 2014 08:26:28 -0800 [thread overview]
Message-ID: <5474ADB4.5070200@redhat.com> (raw)
In-Reply-To: <20141125140130.GC8541@arm.com>
On 11/25/2014 06:01 AM, Will Deacon wrote:
> On Wed, Nov 19, 2014 at 01:24:02AM +0000, Alexander Duyck wrote:
>> diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
>> index 22a969c..a1c589b 100644
>> --- a/Documentation/memory-barriers.txt
>> +++ b/Documentation/memory-barriers.txt
>> @@ -1615,6 +1615,47 @@ There are some more advanced barrier functions:
>> operations" subsection for information on where to use these.
>>
>>
>> + (*) dma_wmb();
>> + (*) dma_rmb();
>> +
>> + These are for use with memory based device I/O to guarantee the ordering
>> + of cache coherent writes or reads with respect to other writes or reads
>> + to cache coherent DMA memory.
> Can you please make it crystal clear that "memory based device I/O" != MMIO?
> If people get these barriers wrong, then debugging will be a nightmare.
I think I'll update that to the following to avoid any confusion:
These are for use with consistent memory to guarantee the ordering
of writes or reads of shared memory accessible to both the CPU and a
DMA capable device.
I will also add a reference to DMA-API.txt at the end for more info on
what consistent memory is.
>> diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h
>> index c6a3e73..d2f81e6 100644
>> --- a/arch/arm/include/asm/barrier.h
>> +++ b/arch/arm/include/asm/barrier.h
>> @@ -43,10 +43,14 @@
>> #define mb() do { dsb(); outer_sync(); } while (0)
>> #define rmb() dsb()
>> #define wmb() do { dsb(st); outer_sync(); } while (0)
>> +#define dma_rmb() dmb(osh)
>> +#define dma_wmb() dmb(oshst)
>> #else
>> #define mb() barrier()
>> #define rmb() barrier()
>> #define wmb() barrier()
>> +#define dma_rmb() barrier()
>> +#define dma_wmb() barrier()
>> #endif
>>
>> #ifndef CONFIG_SMP
>> diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h
>> index 6389d60..a5abb00 100644
>> --- a/arch/arm64/include/asm/barrier.h
>> +++ b/arch/arm64/include/asm/barrier.h
>> @@ -32,6 +32,9 @@
>> #define rmb() dsb(ld)
>> #define wmb() dsb(st)
>>
>> +#define dma_rmb() dmb(oshld)
>> +#define dma_wmb() dmb(oshst)
>> +
>> #ifndef CONFIG_SMP
>> #define smp_mb() barrier()
>> #define smp_rmb() barrier()
> The arm/arm64 bits look fine to me.
>
> Acked-by: Will Deacon <will.deacon@arm.com>
Thanks for the review.
> If we ever see platforms using Linux/dma_alloc_coherent with devices
> mastering from a different outer-shareable domain that the one containing
> the CPUs, then we'll need to revisit this.
Would we just need a system wide memory barrier in that case instead of
an outer shareable memory barrier, or would we need to look as something
like a sync barrier?
- Alex
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Duyck <alexander.h.duyck@redhat.com>
To: Will Deacon <will.deacon@arm.com>
Cc: "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"mathieu.desnoyers@polymtl.ca" <mathieu.desnoyers@polymtl.ca>,
"peterz@infradead.org" <peterz@infradead.org>,
"benh@kernel.crashing.org" <benh@kernel.crashing.org>,
"heiko.carstens@de.ibm.com" <heiko.carstens@de.ibm.com>,
"mingo@kernel.org" <mingo@kernel.org>,
"mikey@neuling.org" <mikey@neuling.org>,
"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
"donald.c.skidmore@intel.com" <donald.c.skidmore@intel.com>,
"matthew.vick@intel.com" <matthew.vick@intel.com>,
"geert@linux-m68k.org" <geert@linux-m68k.org>,
"jeffrey.t.kirsher@intel.com" <jeffrey.t.kirsher@intel.com>,
"romieu@fr.zoreil.com" <romieu@fr.zoreil.com>,
"paulmck@linux.vnet.ibm.com" <paulmck@linux.vnet.ibm.com>,
"nic_swsd@realtek.com" <nic_swsd@realtek.com>,
"michael@ellerman.id.au" <michael@ellerman.id.au>,
"tony.luck@intel.com" <tony.luck@intel.com>,
"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
"oleg@redhat.com" <oleg@redhat.com>,
"schwidefsky@de.ibm.com" <schwidefsky@de.ibm.com>,
"fweisbec@gmail.com" <fweisbec@gmail.com>,
"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: [PATCH v5 2/4] arch: Add lightweight memory barriers dma_rmb() and dma_wmb()
Date: Tue, 25 Nov 2014 08:26:28 -0800 [thread overview]
Message-ID: <5474ADB4.5070200@redhat.com> (raw)
Message-ID: <20141125162628.WvIpAdQFB8BWrMNvuseKq7Ocl_95EkJKPZyi9sZTeG8@z> (raw)
In-Reply-To: <20141125140130.GC8541@arm.com>
On 11/25/2014 06:01 AM, Will Deacon wrote:
> On Wed, Nov 19, 2014 at 01:24:02AM +0000, Alexander Duyck wrote:
>> diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
>> index 22a969c..a1c589b 100644
>> --- a/Documentation/memory-barriers.txt
>> +++ b/Documentation/memory-barriers.txt
>> @@ -1615,6 +1615,47 @@ There are some more advanced barrier functions:
>> operations" subsection for information on where to use these.
>>
>>
>> + (*) dma_wmb();
>> + (*) dma_rmb();
>> +
>> + These are for use with memory based device I/O to guarantee the ordering
>> + of cache coherent writes or reads with respect to other writes or reads
>> + to cache coherent DMA memory.
> Can you please make it crystal clear that "memory based device I/O" != MMIO?
> If people get these barriers wrong, then debugging will be a nightmare.
I think I'll update that to the following to avoid any confusion:
These are for use with consistent memory to guarantee the ordering
of writes or reads of shared memory accessible to both the CPU and a
DMA capable device.
I will also add a reference to DMA-API.txt at the end for more info on
what consistent memory is.
>> diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h
>> index c6a3e73..d2f81e6 100644
>> --- a/arch/arm/include/asm/barrier.h
>> +++ b/arch/arm/include/asm/barrier.h
>> @@ -43,10 +43,14 @@
>> #define mb() do { dsb(); outer_sync(); } while (0)
>> #define rmb() dsb()
>> #define wmb() do { dsb(st); outer_sync(); } while (0)
>> +#define dma_rmb() dmb(osh)
>> +#define dma_wmb() dmb(oshst)
>> #else
>> #define mb() barrier()
>> #define rmb() barrier()
>> #define wmb() barrier()
>> +#define dma_rmb() barrier()
>> +#define dma_wmb() barrier()
>> #endif
>>
>> #ifndef CONFIG_SMP
>> diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h
>> index 6389d60..a5abb00 100644
>> --- a/arch/arm64/include/asm/barrier.h
>> +++ b/arch/arm64/include/asm/barrier.h
>> @@ -32,6 +32,9 @@
>> #define rmb() dsb(ld)
>> #define wmb() dsb(st)
>>
>> +#define dma_rmb() dmb(oshld)
>> +#define dma_wmb() dmb(oshst)
>> +
>> #ifndef CONFIG_SMP
>> #define smp_mb() barrier()
>> #define smp_rmb() barrier()
> The arm/arm64 bits look fine to me.
>
> Acked-by: Will Deacon <will.deacon@arm.com>
Thanks for the review.
> If we ever see platforms using Linux/dma_alloc_coherent with devices
> mastering from a different outer-shareable domain that the one containing
> the CPUs, then we'll need to revisit this.
Would we just need a system wide memory barrier in that case instead of
an outer shareable memory barrier, or would we need to look as something
like a sync barrier?
- Alex
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Duyck <alexander.h.duyck@redhat.com>
To: Will Deacon <will.deacon@arm.com>
Cc: "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"mathieu.desnoyers@polymtl.ca" <mathieu.desnoyers@polymtl.ca>,
"peterz@infradead.org" <peterz@infradead.org>,
"benh@kernel.crashing.org" <benh@kernel.crashing.org>,
"heiko.carstens@de.ibm.com" <heiko.carstens@de.ibm.com>,
"mingo@kernel.org" <mingo@kernel.org>,
"mikey@neuling.org" <mikey@neuling.org>,
"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
"donald.c.skidmore@intel.com" <donald.c.skidmore@intel.com>,
"matthew.vick@intel.com" <matthew.vick@intel.com>,
"geert@linux-m68k.org" <geert@linux-m68k.org>,
"jeffrey.t.kirsher@intel.com" <jeffrey.t.kirsher@intel.com>,
"romieu@fr.zoreil.com" <romieu@fr.zoreil.com>,
"paulmck@linux.vnet.ibm.com" <paulmck@linux.vnet.ibm.com>,
"nic_swsd@realtek.com" <nic_
Subject: Re: [PATCH v5 2/4] arch: Add lightweight memory barriers dma_rmb() and dma_wmb()
Date: Tue, 25 Nov 2014 08:26:28 -0800 [thread overview]
Message-ID: <5474ADB4.5070200@redhat.com> (raw)
In-Reply-To: <20141125140130.GC8541@arm.com>
On 11/25/2014 06:01 AM, Will Deacon wrote:
> On Wed, Nov 19, 2014 at 01:24:02AM +0000, Alexander Duyck wrote:
>> diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
>> index 22a969c..a1c589b 100644
>> --- a/Documentation/memory-barriers.txt
>> +++ b/Documentation/memory-barriers.txt
>> @@ -1615,6 +1615,47 @@ There are some more advanced barrier functions:
>> operations" subsection for information on where to use these.
>>
>>
>> + (*) dma_wmb();
>> + (*) dma_rmb();
>> +
>> + These are for use with memory based device I/O to guarantee the ordering
>> + of cache coherent writes or reads with respect to other writes or reads
>> + to cache coherent DMA memory.
> Can you please make it crystal clear that "memory based device I/O" != MMIO?
> If people get these barriers wrong, then debugging will be a nightmare.
I think I'll update that to the following to avoid any confusion:
These are for use with consistent memory to guarantee the ordering
of writes or reads of shared memory accessible to both the CPU and a
DMA capable device.
I will also add a reference to DMA-API.txt at the end for more info on
what consistent memory is.
>> diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h
>> index c6a3e73..d2f81e6 100644
>> --- a/arch/arm/include/asm/barrier.h
>> +++ b/arch/arm/include/asm/barrier.h
>> @@ -43,10 +43,14 @@
>> #define mb() do { dsb(); outer_sync(); } while (0)
>> #define rmb() dsb()
>> #define wmb() do { dsb(st); outer_sync(); } while (0)
>> +#define dma_rmb() dmb(osh)
>> +#define dma_wmb() dmb(oshst)
>> #else
>> #define mb() barrier()
>> #define rmb() barrier()
>> #define wmb() barrier()
>> +#define dma_rmb() barrier()
>> +#define dma_wmb() barrier()
>> #endif
>>
>> #ifndef CONFIG_SMP
>> diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h
>> index 6389d60..a5abb00 100644
>> --- a/arch/arm64/include/asm/barrier.h
>> +++ b/arch/arm64/include/asm/barrier.h
>> @@ -32,6 +32,9 @@
>> #define rmb() dsb(ld)
>> #define wmb() dsb(st)
>>
>> +#define dma_rmb() dmb(oshld)
>> +#define dma_wmb() dmb(oshst)
>> +
>> #ifndef CONFIG_SMP
>> #define smp_mb() barrier()
>> #define smp_rmb() barrier()
> The arm/arm64 bits look fine to me.
>
> Acked-by: Will Deacon <will.deacon@arm.com>
Thanks for the review.
> If we ever see platforms using Linux/dma_alloc_coherent with devices
> mastering from a different outer-shareable domain that the one containing
> the CPUs, then we'll need to revisit this.
Would we just need a system wide memory barrier in that case instead of
an outer shareable memory barrier, or would we need to look as something
like a sync barrier?
- Alex
next prev parent reply other threads:[~2014-11-25 16:28 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-19 1:23 [PATCH v5 0/4] arch: Add lightweight memory barriers for coherent memory access Alexander Duyck
2014-11-19 1:23 ` [PATCH v5 1/4] arch: Cleanup read_barrier_depends() and comments Alexander Duyck
2014-11-19 1:24 ` [PATCH v5 2/4] arch: Add lightweight memory barriers dma_rmb() and dma_wmb() Alexander Duyck
2014-11-25 14:01 ` Will Deacon
2014-11-25 14:01 ` Will Deacon
2014-11-25 14:01 ` Will Deacon
2014-11-25 16:26 ` Alexander Duyck [this message]
2014-11-25 16:26 ` Alexander Duyck
2014-11-25 16:26 ` Alexander Duyck
2014-11-26 16:04 ` Will Deacon
2014-11-26 16:04 ` Will Deacon
2014-11-26 16:04 ` Will Deacon
2014-11-25 23:15 ` Benjamin Herrenschmidt
2014-11-19 1:24 ` [PATCH v5 3/4] r8169: Use dma_rmb() and dma_wmb() for DescOwn checks Alexander Duyck
2014-11-19 1:24 ` [PATCH v5 4/4] fm10k/igb/ixgbe: Use dma_rmb on Rx descriptor reads Alexander Duyck
2014-11-19 1:28 ` Jeff Kirsher
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=5474ADB4.5070200@redhat.com \
--to=alexander.h.duyck@redhat.com \
--cc=benh@kernel.crashing.org \
--cc=donald.c.skidmore@intel.com \
--cc=geert@linux-m68k.org \
--cc=heiko.carstens@de.ibm.com \
--cc=jeffrey.t.kirsher@intel.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=matthew.vick@intel.com \
--cc=mikey@neuling.org \
--cc=mingo@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=romieu@fr.zoreil.com \
--cc=will.deacon@arm.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.