LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Michael Ellerman <michael@ellerman.id.au>
To: akepner@sgi.com
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
	Grant Grundler <grundler@parisc-linux.org>,
	Tony Luck <tony.luck@intel.com>,
	Jesse Barnes <jbarnes@virtuousgeek.org>,
	Jes Sorensen <jes@sgi.com>,
	Randy Dunlap <randy.dunlap@oracle.com>,
	Roland Dreier <rdreier@cisco.com>,
	David Miller <davem@davemloft.net>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	linux-kernel@vger.kernel.org, Mark Nelson <mdnelson@au1.ibm.com>
Subject: Re: [PATCH 1/3 v3] dma: document dma_{un}map_{single|sg}_attrs() interface
Date: Thu, 06 Mar 2008 17:01:46 +1100	[thread overview]
Message-ID: <1204783306.14874.37.camel@concordia.ozlabs.ibm.com> (raw)
In-Reply-To: <20080305181307.GR17802@sgi.com>

[-- Attachment #1: Type: text/plain, Size: 2098 bytes --]

On Wed, 2008-03-05 at 10:13 -0800, akepner@sgi.com wrote:
> On Fri, Feb 29, 2008 at 12:37:56PM -0600, James Bottomley wrote:
> > ....
> > To be honest, I still don't like the name.  SYNC_ON_WRITE is the SN2
> > implementation.  What it's actually doing is implementing strict
> > ordering semantics.  I think it should really be
> > DMA_ATTR_STRICT_ORDERING (with a corresponding
> > DMA_ATTR_RELAXED_ORDERING)....
> 
> I've been thinking about a new name, but don't like 
> DMA_ATTR_STRICT_ORDERING. 
> 
> What I'm trying to do is to establish order (across 
> a NUMA fabric) of DMA to different memory regions, i.e., 
> DMA to memory region A forces all outstanding DMA (to 
> memory regions B, C,....) to complete first.
> 
> DMA_ATTR_STRICT_ORDERING sounds like a PCI thing to me, 
> and this is a NUMA interconnect thing.


It's not a matter of whether it's a PCI thing or a NUMA thing. The name
of the attribute needs to reflect the semantics of what the driver
perceives, along the entire path from the device including PCI and NUMA
and other bits.

How the attribute is implemented is up to the arch code, it can decide
if it sets attributes on the PHB or the device or in the NUMA
interconnect or whatever.

For a single mapping, it's fairly straight forward to define two obvious
cases:
 - strict ordering, all accesses to this mapping are ordered.
 - weak ordering (none, relaxed ..) - accesses to this mapping are not 
   ordered in anyway.

Where I think it gets confusing is the semantics between mappings with
different attributes. If I map region A weak and then region B strict,
does an access to region B have any effect on accesses to region A?

It sounds like in your case the answer is yes - but I don't know if
that's clearly the right answer.

/me scratches his head :)

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2008-03-06  6:01 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-28  3:24 akepner
2008-02-29  2:45 ` Michael Ellerman
2008-02-29 18:25   ` Grant Grundler
2008-02-29 18:37     ` James Bottomley
2008-03-01  2:56       ` Benjamin Herrenschmidt
2008-03-01  3:11         ` Jesse Barnes
2008-03-01  7:18         ` Grant Grundler
2008-03-05 18:13       ` akepner
2008-03-05 19:02         ` Jesse Barnes
2008-03-06  6:01         ` Michael Ellerman [this message]
2008-03-12  1:19           ` akepner
2008-03-14  4:13             ` Grant Grundler
2008-03-14  4:30             ` Michael Ellerman
2008-03-14  5:21               ` Grant Grundler
2008-03-14 16:40                 ` Jesse Barnes
2008-03-18  1:08                 ` Michael Ellerman
2008-03-20  0:32               ` akepner
2008-02-29 21:23   ` akepner

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=1204783306.14874.37.camel@concordia.ozlabs.ibm.com \
    --to=michael@ellerman.id.au \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=akepner@sgi.com \
    --cc=benh@kernel.crashing.org \
    --cc=davem@davemloft.net \
    --cc=grundler@parisc-linux.org \
    --cc=jbarnes@virtuousgeek.org \
    --cc=jes@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mdnelson@au1.ibm.com \
    --cc=randy.dunlap@oracle.com \
    --cc=rdreier@cisco.com \
    --cc=tony.luck@intel.com \
    --subject='Re: [PATCH 1/3 v3] dma: document dma_{un}map_{single|sg}_attrs() interface' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).