public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: Jes Sorensen <jes@sgi.com>,
	akepner@sgi.com, Randy Dunlap <randy.dunlap@oracle.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	rdreier@cisco.com, linux-ia64 <linux-ia64@vger.kernel.org>
Subject: Re: [PATCH 2/3] dma: override "dma_flags_set_dmaflush" for sn-ia64
Date: Wed, 22 Aug 2007 16:03:23 +0000	[thread overview]
Message-ID: <200708220903.23702.jbarnes@virtuousgeek.org> (raw)
In-Reply-To: <1187791358.3410.1.camel@localhost.localdomain>

On Wednesday, August 22, 2007 7:02:38 am James Bottomley wrote:
> On Wed, 2007-08-22 at 09:39 +0200, Jes Sorensen wrote:
> > James Bottomley wrote:
> > > On Tue, 2007-08-21 at 17:34 -0700, akepner@sgi.com wrote:
> > >> The term "posted DMA" is used to describe this behavior in the Altix
> > >> Device Driver Writer's Guide, but it may be confusing things here.
> > >> Maybe a better term will suggest itself if I can clarify....
> > >
> > > OK, but posted DMA has a pretty specific meaning in terms of PCI, hence
> > > the confusion.
> >
> > Maybe it would be more better to refer to this as 'out of order DMA'?
>
> Or Relaxed ordering DMA ... that's why the readX_relaxed()?
>
> > >> 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 interconnect (it's specifically not a PCI reordering.)
> > >
> > > This is mmiowb and read_relaxed() again, isn't it?
> >
> > I believe it's the same problem, except this time it's when exposing
> > structures to userland.
>
> Hmm, so how does another kernel API exposing mmiowb in a different way
> help with this?  Surely, if the driver is exporting something to user
> space, it's simply up to the driver to call mmiowb when the user says
> it's done?

mmiowb() is for PIO->device.  This interface is for DMA->memory (see akepner's 
other mail).

The problem is a DMA write (say to a completion queue) from a device may imply 
something about another DMA write from the same device (say the actual data).  
If the completion queue write arrives first (which can happen on sn2), the 
driver must ensure that the rest of the outstanding DMA is complete prior to 
looking at the completion queue status.  It can either use a regular PIO read 
to do this (i.e. a non-relaxed one) or set a flag on the completion queue DMA 
address that makes it act as a barrier wrt other DMA, which is what akepner's 
patch does (which should be much more efficient that using a PIO read to 
guarantee DMA writes have completed).

Jesse

  reply	other threads:[~2007-08-22 16:03 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20070818002746.GU1813@sgi.com>
2007-08-20  8:24 ` [PATCH 2/3] dma: override "dma_flags_set_dmaflush" for sn-ia64 Jes Sorensen
2007-08-20 16:07   ` akepner
2007-08-21 19:35   ` akepner
2007-08-21 20:05     ` Randy Dunlap
2007-08-21 20:55       ` James Bottomley
2007-08-22  0:34         ` akepner
2007-08-22  1:14           ` James Bottomley
2007-08-22  7:39             ` Jes Sorensen
2007-08-22 14:02               ` James Bottomley
2007-08-22 16:03                 ` Jesse Barnes [this message]
2007-08-22 16:44                   ` James Bottomley
2007-08-22 16:51                     ` Jesse Barnes
2007-08-22 17:04                       ` James Bottomley
2007-08-22 17:03                         ` Jes Sorensen
2007-08-22 18:10                           ` James Bottomley
2007-08-23  8:45                             ` Jes Sorensen
2007-08-22 17:17                         ` Jesse Barnes
2007-08-22 18:13                           ` James Bottomley
2007-08-22 18:44                             ` akepner
2007-08-23  5:58               ` Jeremy Higdon
2007-08-22 15:54             ` akepner
2007-08-21 20:16     ` Matthew Wilcox
2007-08-21 21:37       ` akepner
2007-08-22  7:44       ` Jes Sorensen

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=200708220903.23702.jbarnes@virtuousgeek.org \
    --to=jbarnes@virtuousgeek.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=akepner@sgi.com \
    --cc=jes@sgi.com \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=randy.dunlap@oracle.com \
    --cc=rdreier@cisco.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox