Add a new parameter, dmasync, to the ib_umem_get() prototype. Use
dmasync = 1 when mapping user-allocated CQs with ib_umem_get().
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
---
drivers/infiniband/core/umem.c | 17 +
drivers/infiniband/hw/amso1100/c2_provider.
Change all ia64 machvecs to use the new dma_{un}map_*_attrs()
interfaces. Implement the old dma_{un}map_*() interfaces in
terms of the corresponding new interfaces. For ia64/sn, make
use of one dma attribute, DMA_ATTR_SYNC_ON_WRITE.
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
---
arch/ia6
Document the new dma_{un}map_{single|sg}_attrs() functions.
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
---
DMA-API.txt| 65 +
DMA-attributes.txt | 29 +++
2 files changed, 94 insertions(+)
diff --git a/D
Introduce a new interface for passing architecture-specific
attributes when memory is mapped and unmapped for DMA. Give
the interface a default implementation which ignores
attributes.
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
---
dma-mapping.h | 35 +++
On Thu, Jan 31, 2008 at 03:38:48PM -0700, Grant Grundler wrote:
Thanks for looking through this.
I'll send an updated patchset that addresses your comments
as soon as I can - probably around Monday.
> ...
> > +struct dma_attrs encapsulates a set of "dma attributes". For the
> > +definition of
On Wed, Jan 30, 2008 at 07:00:11PM -0800, Roland Dreier wrote:
> > @@ -72,6 +73,8 @@ static void __ib_umem_release(struct ib_device *dev,
> struct ib_umem *umem, int d
> > * @addr: userspace virtual address to start at
> > * @size: length of region to pin
> > * @access: IB_ACCESS_xxx fla
On Wed, Jan 30, 2008 at 11:25:58AM -0600, James Bottomley wrote:
> In general, the patches look reasonable to me. Just an observation:
>
> On Tue, 2008-01-29 at 21:52 -0800, [EMAIL PROTECTED] wrote:
> > diff --git a/include/linux/dma-attrs.h b/include/linux/dma-attrs.h
> > index e69de29..31af292
Add MTHCA_MR_DMABARRIER to mthca's API, increment ABI version,
and make use of MTHCA_MR_DMABARRIER when mapping a user-allocated
memory region with ib_umem_get().
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
--
drivers/infiniband/core/umem.c | 15 +---
drivers/in
Add a new parameter, dmabarrier, to the ib_umem_get()
prototype.
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
--
drivers/infiniband/core/umem.c |2 +-
drivers/infiniband/hw/amso1100/c2_provider.c |2 +-
drivers/infiniband/hw/cxgb3/iwch_provider.c |2 +-
drivers
Change all ia64 machvecs to use the new dma_{un}map_*_attrs()
interfaces. Implement the old dma_{un}map_*() interfaces in
terms of the corresponding new interfaces. For ia64/sn, make
use of one dma attribute, DMA_ATTR_BARRIER.
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
--
arch/ia64/hp
Introduce a new interface for passing architecture-specific
attributes when memory is mapped and unmapped for DMA. Give
the interface a default implementation which ignores
attributes.
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
--
dma-mapping.h | 33 +
Document the new dma_{un}map_{single|sg}_attrs() functions.
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
--
DMA-API.txt | 63
1 files changed, 63 insertions(+)
diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.tx
Thanks for the review.
An updated version of the patch follows.
On Tue, Jan 22, 2008 at 08:59:50PM -0800, Roland Dreier wrote:
> > ...
> > +static inline int dma_set_attr(struct dma_attrs *attrs, unsigned attr) {
>
> maybe this would be cleaner if you named the DMA_ATTR enum and used
> that
Here's a new interface for passing attributes to the dma mapping
and unmapping routines. (I have patches that make use of the
interface as well, but let's discuss this piece first.)
For ia64, new machvec entries replace the dma map/unmap interface,
and the old interface is implemented in terms
On Wed, Jan 09, 2008 at 01:00:38PM -0800, Roland Dreier wrote:
> .
> The reason this hasn't been an issue until now is that almost all
> drivers work correctly if the Altix code just sets the "flush" bit for
> memory allocated via the consistent/coherent allocators. However, if
> we want the d
On Tue, Jan 08, 2008 at 12:21:44PM -0600, James Bottomley wrote:
> ...
> But the point is that the Altix does something non-standard but which
> was later standardised (in a different way) largely so others could also
> benefit from the relaxed ordering speedup.
>
When you say that Altix does "som
On Tue, Jan 08, 2008 at 05:50:54PM +, Christoph Hellwig wrote:
> ...
> Onething I've missed with these patches is drivers actually using
> it. What driver actually needs it and why don't you send patches
> for them?
Some IB drivers need this. Here's an example with the ib_mthca
driver.
--
On Tue, Jan 08, 2008 at 10:27:08AM -0600, James Bottomley wrote:
> All of the attributes I can see adding are
> bus specific (even to the extent that PCIe ones wouldn't apply to PCI
> for instance)
>
The attribute I want to pass isn't bus-specific, but architecture-
specific.
--
Arthur
On Tue, Jan 08, 2008 at 09:58:31AM +0100, Ingo Molnar wrote:
>
> * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> > +enum dma_data_attr {
> > + DMA_ATTR_BARRIER = (1 << 0),
> > + DMA_ATTR_FOO = (1 << 1),
> > + DMA_ATTR_GOO = (1 << 2),
> > + DMA_ATTR_MAX = (1 << 3),
> > +};
>
> FOO/GOO
Allow dma "attributes" to be passed to dma_map_*/dma_unmap_*
implementations on x86_64.
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
--
arch/x86/kernel/pci-calgary_64.c | 13 -
arch/x86/kernel/pci-gart_64.c| 27 +--
arch/x86/kernel/pci-nommu_64.c
Allow dma "attributes" to be used by dma_map_*/dma_unmap_*
implementations on the ia64/sn2 architecture. (This one also
includes some changes to lib/swiotlb.c which aren't specific
to ia64/sn2.)
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
--
arch/ia64/sn/pci/pci_dma.c | 45 ++
Place the definition of enum dma_data_direction in its own
include file, and add the definition of enum dma_data_attr
and some simple routines for manipulating the direction and
attributes.
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
--
dma-direction.h | 53 +
The following patchset allows additional "attributes" to be
passed to dma_map_*/dma_unmap_* implementations. (The reason
why this is useful/necessary has been mentioned several times,
most recently here:
http://marc.info/?l=linux-kernel&m=119258541412724&w=2.)
This is incomplete in that only i
On Fri, Dec 21, 2007 at 07:56:25AM +1100, Benjamin Herrenschmidt wrote:
> ...
> Can't you just have a primitive to sync things up that you call
> explicitely from your driver after fetching a new status entry ?
>
Well, the only mechanisms I know to get things synced are the ones
I mentioned befo
On Tue, Dec 18, 2007 at 09:59:24PM +0100, Stefan Richter wrote:
>
> From its purpose it sounds like you need this only for few special
> memory regions which would typically be mapped by dma_map_single()
We need the _sg versions too, as Roland already mentioned.
> and
> furthermore that dr
On Tue, Dec 18, 2007 at 09:59:24PM +0100, Stefan Richter wrote:
>
> So that would be option 3) of yours, though without your attrs
> parameter. Do you expect the need for even more flags for other kinds
> of special behavior?
I was hoping to keep the option of adding additional
flags, but
On Tue, Dec 18, 2007 at 05:50:42PM +0100, Stefan Richter wrote:
> Do I understand correctly?: A device and the CPUs communicate via two
> separate memory areas: A data buffer and a status FIFO. The NUMA
> interconnect may reorder accesses of the device to the areas. (Write
> accesses? Read ac
Waaay back in October I sent some patches for passing additional
attributes to the dma_map_* routines:
http://marc.info/?l=linux-kernel&m=119137949604365&w=2
This is somthing needed for ia64 Altix NUMA machines (as described
in that thread).
Several folks objected to the approach I used - it
[reply to the series of three mails below]
On Tue, Oct 16, 2007 at 08:27:28PM -0700, Andrew Morton wrote:
> On Tue, 16 Oct 2007 18:41:28 -0700 [EMAIL PROTECTED] wrote:
>
> > +#define DMA_BARRIER_ATTR 0x1
> > +#ifndef ARCH_USES_DMA_ATTRS
> > +static inline int dma_flags_set_attr(u32 attr, enum
Document the dma_flags_set/get_*() interfaces.
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
---
DMA-API.txt | 38 ++
1 files changed, 38 insertions(+)
diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index b939ebb..00919b0 100644
--
Redefine dma_flags_set/get_*() for sn-ia64.
dma_flags_set_attr() "borrows" bits from the dma_map_* routines'
direction arguments (renamed "flags"). It uses the borrowed bits
to pass additional attributes.
dma_flags_get_dir() and dma_flags_get_attr() return the direction
and attributes that w
Introduce the dma_flags_set/get_*() interfaces and give them
default implementations.
Architectures which allow DMA to be reordered between a device and
host memory (within a NUMA interconnect) can redefine these to allow
a driver to explicitly synchronize DMA from the device when necessary.
On Tue, Oct 02, 2007 at 08:10:23PM -0700, David Miller wrote:
> From: [EMAIL PROTECTED]
> Date: Tue, 2 Oct 2007 19:49:06 -0700
>
> >
> > Pass a "dmabarrier" argument to ib_umem_get() and use the new
> > argument to control setting the DMA_BARRIER_ATTR attribute on
> > the memory that ib_umem_ge
On Wed, Oct 03, 2007 at 05:56:45AM +0300, Heikki Orsila wrote:
> On Tue, Oct 02, 2007 at 07:50:07PM -0700, [EMAIL PROTECTED] wrote:
> > +struct mthca_reg_mr {
> > + __u32 mr_attrs;
> > +#define MTHCA_MR_DMAFLUSH 0x1 /* flush in-flight DMA on a write to
> > +* mem
Allow setting a "dmabarrier" when the mthca driver registers user-
allocated memory.
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
---
mthca_provider.c |7 ++-
mthca_user.h | 10 +-
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/m
Document dma_flags_set_attr().
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
---
DMA-API.txt | 27 +++
1 files changed, 27 insertions(+)
diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index cc7a8c3..16e15c0 100644
--- a/Documentation/DMA-API.tx
Pass a "dmabarrier" argument to ib_umem_get() and use the new
argument to control setting the DMA_BARRIER_ATTR attribute on
the memory that ib_umem_get() maps for DMA.
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
---
drivers/infiniband/core/umem.c |8 ++--
drivers/i
define dma_flags_set_attr() for sn-ia64 - it "borrows" bits from
the direction argument (renamed "flags") to the dma_map_* routines
to pass an additional attributes. Also define routines to retrieve
the original direction and attribute from "flags".
Signed-off-by: Arthur Kepner <[EMAIL PROTEC
Introduce the dma_flags_set_attr() interface and give it a default
no-op implementation.
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
---
dma-mapping.h |8
1 files changed, 8 insertions(+)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 2dc21cb..
On Altix, DMA may be reordered between a device and host memory.
This reordering can happen in the NUMA interconnect, and it usually
results in correct operation and improved performance. In some
situations it may be necessary to explicitly synchronize DMA from
the device.
This patchset allow
On Fri, Sep 28, 2007 at 03:43:39PM -0700, David Miller wrote:
>
> My only beef with this patch set is that it seems
> a bit much to create a totally new function name every
> time we want to set some kind of new attribute on some
> DMA object. Why not add a "dma_set_flags()" or similar
> that
On Fri, Sep 28, 2007 at 12:50:00PM -0700, Roland Dreier wrote:
> Sorry for not mentioning this earlier, but this patch should really be
> two (or more) patches: one to add dmabarrier support to the core user
> memory stuff in drivers/infiniband, and a second one to add support to
> mthca (and more
Use the dma_flags_set_dmabarrier() interface to allow a "dmabarrier"
attribute to be associated with user-allocated memory. (For now,
it's only implemented for mthca.)
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
---
drivers/infiniband/core/umem.c |7 +--
drivers/infi
Document dma_flags_set_dmabarrier().
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
---
DMA-API.txt | 26 ++
1 files changed, 26 insertions(+)
diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index cc7a8c3..5fc0bba 100644
--- a/Documentation/DMA-AP
define dma_flags_set_dmabarrier() for sn-ia64 - it "borrows"
bits from the direction argument (renamed "flags") to the
dma_map_* routines to pass an additional "dmabarrier" attribute.
Also define routines to retrieve the original direction and
attribute from "flags".
Signed-off-by: Arthur Kepner
Introduce the dma_flags_set_dmabarrier() interface and give it
a default no-op implementation.
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
---
dma-mapping.h |6 ++
1 files changed, 6 insertions(+)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 2dc21
On Altix, DMA may be reordered between a device and host memory.
This reordering can happen in the NUMA interconnect, and it usually
results in correct operation and improved performance. In some
situations it may be necessary to explicitly synchronize DMA from
the device.
This patchset allow
On Wed, Sep 26, 2007 at 12:49:50AM -0600, Grant Grundler wrote:
[edited out several points that I think have been already
addresed by others in this thread.]
>
> Defining it terms of completion queues won't mean much to most folks.
> Better to add a description of completion queues to the D
On Tue, Sep 25, 2007 at 10:13:33PM -0700, Randy Dunlap wrote:
> On Tue, 25 Sep 2007 17:00:57 -0700 [EMAIL PROTECTED] wrote:
> ..
> 1. Function signature should be on one line if possible (and it is).
> Aw crud, I looked at dma-mapping.h and it uses this format sometimes.
> Well, it's undesirab
Use the dma_flags_set_dmaflush() interface to allow a "dmaflush"
attribute to be associated with user-allocated memory. (For now,
it's only implemented for mthca.)
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
--
drivers/infiniband/core/umem.c |7 +--
drivers/infiniban
define dma_flags_set_dmaflush() for sn-ia64 - it "borrows"
bits from the direction argument (renamed "flags") to the
dma_map_* routines to pass an additional "dmaflush" attribute.
Also define routines to retrieve the original direction and
attribute from "flags".
Signed-off-by: Arthur Kepner <[EM
Document dma_flags_set_dmaflush().
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
--
DMA-mapping.txt | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/Documentation/DMA-mapping.txt b/Documentation/DMA-mapping.txt
index e07f253..31e3234 100644
--- a
This is a followup to http://lkml.org/lkml/2007/8/24/280
Despite Grant's desire for a more elegant solution, there's
not much new here. I moved the API change from pci.h to
dma-mapping.h and removed the pci_ prefix from the name.
Problem Description
---
On Altix, DMA may be r
Introduce the dma_flags_set_dmaflush() interface and give it
a default no-op implementation.
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
--
dma-mapping.h |7 +++
1 file changed, 7 insertions(+)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 2dc21cb..
On Mon, Aug 27, 2007 at 04:05:48PM -0600, Grant Grundler wrote:
> .
> After reading the thread, my take is we need a more elegant way for a
> device driver to handle registration of DMA regions allocated by user
> space. The API would "make this page/region act like dma_alloc_coherent()".
> Th
On Fri, Aug 24, 2007 at 02:47:11PM -0700, David Miller wrote:
>
> Someone should reference that thread _now_ before this discussion goes
> too far and we repeat a lot of information ..
Here's part of the thread:
http://marc.info/?t=11159530601&r=1&w=2
Also, Jamal's paper may be of i
Document pci_dma_flags_set_dmaflush().
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
--
DMA-mapping.txt | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/Documentation/DMA-mapping.txt b/Documentation/DMA-mapping.txt
index e07f253..32f88e5 100644
define pci_dma_flags_set_dmaflush() for sn-ia64 - it "borrows"
bits from the direction argument (renamed "flags") to the
dma_map_* routines to pass an additional "dmaflush" attribute.
Also define routines to retrieve the original direction and
attribute from "flags".
Signed-off-by: Arthur Ke
Introduce the pci_dma_flags_set_dmaflush() interface and give it
a default no-op implementation.
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
--
pci.h |7 +++
1 file changed, 7 insertions(+)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index e7d8d4e..cee5709 100644
--- a/
On Altix, DMA may be reordered within the NUMA interconnect.
This can be a problem with Infiniband, where DMA to Completion
Queues can race with data DMA. This patchset allows a driver
to associate a memory region with a "dmaflush" attribute, so
that writes to the memory region flush in-flight
On Fri, Aug 24, 2007 at 03:59:16PM +0200, Jan-Bernd Themann wrote:
> ...
> 3) On modern systems the incoming packets are processed very fast. Especially
> on SMP systems when we use multiple queues we process only a few packets
> per napi poll cycle. So NAPI does not work very well here a
On Wed, Aug 22, 2007 at 01:13:04PM -0500, James Bottomley wrote:
> ..
> OK ... I think this is definitely a PCI specific API ... and probably a
> generic one for requesting order flushes in devices that have negotiated
> relaxed ordering. Do you want to start a new thread on linux-pci and cc
>
On Tue, Aug 21, 2007 at 08:14:09PM -0500, James Bottomley wrote:
> On Tue, 2007-08-21 at 17:34 -0700, [EMAIL PROTECTED] wrote:
> .
> > On Altix, DMA from a device isn't guaranteed to arrive in host memory
> > in the order it was sent from the device. This reordering can happen
> > in the NUMA
On Tue, Aug 21, 2007 at 03:55:29PM -0500, James Bottomley wrote:
> .
> Almost every platform supports posted DMA ... its a property of most PCI
> bridge chips.
>
The term "posted DMA" is used to describe this behavior in the Altix
Device Driver Writer's Guide, but it may be confusing things
On Tue, Aug 21, 2007 at 02:16:32PM -0600, Matthew Wilcox wrote:
>
> So, let me try to understand ... your hardware allows writes from the
> device to pass other writes from the device? Doesn't that violate the
> PCI spec? I'm thinking about this (page 43 of PCI 2.3):
>
I should have stated
> I'm a little concerned about changing the API for the dma_ foo
> functions, which are defined cross platform. If you want to change
> that, I think it will require updating the documentation explaining
> it.
What do you think of the following? (And is there anyone else
I should be cc-ing f
On Mon, Aug 20, 2007 at 10:24:53AM +0200, Jes Sorensen wrote:
> I'm a little concerned about changing the API for the dma_ foo
> functions, which are defined cross platform. If you want to change
> that, I think it will require updating the documentation explaining
> it.
Good idea. I'll post a do
Add a new parameter "dmaflush" to ib_umem_get, and update all
callers. For now only the mthca IB driver makes use of the new
parameter.
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
--
drivers/infiniband/core/umem.c |8 ++--
drivers/infiniband/hw/amso1100/c2_provider.
Introduce a no-op stub function "dma_flags_set_dmaflush". Arches
can override this if necessary to associate a "dmaflush" attribute
with a DMA-able memory region. In-flight DMA will be flushed to
host memory when a memory region with the dmaflush attribute is
written to.
Signed-off-by: Arthur
Define ARCH_DOES_POSTED_DMA, and override the dma_flags_set_dmaflush
function. Also define dma_flags_get_direction, dma_flags_get_dmaflush
to retrieve the direction and "dmaflush attribute" from flags
passed to the sn_dma_map_* functions.
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
--
a
Altix supports "posted DMA", so that DMA may complete out
of order. In some cases it's necessary for a driver to
ensure that in-flight DMA has been flushed to memory for
correct operation.
In particular this can be a problem with Infiniband, where
writes to Completion Queues can race with DMA
Altix supports "posted DMA", so that DMA may complete out
of order. In some cases it's necessary for a driver to
ensure that in-flight DMA has been flushed to memory for
correct operation.
In particular this can be a problem with Infiniband, where
writes to Completion Queues can race with DMA
On Tue, Jul 17, 2007 at 01:16:58PM +0300, Muli Ben-Yehuda wrote:
> On Mon, Jul 16, 2007 at 07:18:12PM -0700, [EMAIL PROTECTED] wrote:
> .
> > --- a/include/linux/dma-mapping.h
> > +++ b/include/linux/dma-mapping.h
> > @@ -95,4 +95,11 @@ static inline void dmam_release_declared_memory(struct
>
Altix supports "posted DMA", and DMA can complete out of
order due to reordering within the NUMA-interconnect.
One of the synchronization mechanisms to flush in-flight
DMA is to write to an address which has a special "barrier"
bit set. (The other mechanism is to generate an interrupt.)
For now,
74 matches
Mail list logo
