public inbox for linux-kernel@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 09:51:04 -0700	[thread overview]
Message-ID: <200708220951.05101.jbarnes@virtuousgeek.org> (raw)
In-Reply-To: <1187801095.3410.49.camel@localhost.localdomain>

On Wednesday, August 22, 2007 9:44:55 am James Bottomley wrote:
> > 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).
>
> This is a violation of the PCI spec, isn't it, like Matthew pointed out?
> The only time a device->host DMA transaction shouldn't follow strict
> ordering is when the device sets the relaxed hint in its PCI registers.

Yeah, it is.  Whether its allowed in PCIe depends on how you read the spec 
(but either way it would need to be explicitly enabled).

For better or for worse, Altix hardware always behaves this way (well mostly 
for the better, since most device protocols don't care as they involve PIO, 
and out of order completion is *much* faster on Altix than strict ordering).

Arthur's patch is pretty straightfoward though, so unless someone can think of 
a better way of hiding this architectural detail in lower level code it's 
probably a good thing to add (especially given that future revs of PCIe will 
probably allow this behavior, and hopefully less ambiguously than the current 
spec).

Jesse

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

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-18  0:27 [PATCH 2/3] dma: override "dma_flags_set_dmaflush" for sn-ia64 akepner
2007-08-20  8:24 ` 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
2007-08-22 16:44                   ` James Bottomley
2007-08-22 16:51                     ` Jesse Barnes [this message]
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=200708220951.05101.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