From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Roland Dreier <rdreier@cisco.com>
Cc: akepner@sgi.com, Tony Luck <tony.luck@intel.com>,
Grant Grundler <grundler@parisc-linux.org>,
Jesse Barnes <jbarnes@virtuousgeek.org>,
Jes Sorensen <jes@sgi.com>,
Randy Dunlap <randy.dunlap@oracle.com>,
David Miller <davem@davemloft.net>,
Muli Ben-Yehuda <muli@il.ibm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC/PARTIAL PATCH 0/3] dma: passing "attributes" to dma_map_* routines
Date: Tue, 08 Jan 2008 12:21:44 -0600 [thread overview]
Message-ID: <1199816504.3534.59.camel@localhost.localdomain> (raw)
In-Reply-To: <adawsqkjipz.fsf@cisco.com>
On Tue, 2008-01-08 at 10:05 -0800, Roland Dreier wrote:
> > > I think the case before us that Arthur is dealing with is a
> > > counterexample for this: there's nothing bus-specific about it all.
> > > The issue is related to reordering of DMAs within the Altix system
> > > fabric, after they've left the PCI world. This issue would be present
> > > no matter what kind of host bridge you hook up to the system fabric,
> > > be it PCI-X, PCIe, ISA, MCA or whatever.
>
> > But it is: for performance reasons, the Altix boxes have a rather non
> > standard PCI bridge implementation that gives relaxed ordering on the
> > PCI bus.
>
> I don't think this is accurate. As I understand things, the reordering
> happens within the Altix system interconnect
Which would be a platform bus, rather like the runway bus in parisc
systems ...
> -- nothing to do with the
> PCI bridge hanging off this fabric. It is "platform" behavior and I
> think is properly handled within the dma_ API, which exists to
> abstract platforms.
> > This behaviour was later standardised to some degree in PCIe,
> > so you could argue they actually have an altix specific PCI bus (PCIa
> > anyone?). Regardless, other manufacturers are probably going to demand
> > something equivalent to this based on the PCIe standard, so we should be
> > ready for it, hence the desire for the bus specific attributes.
>
> But:
> a) The Altix has PCI-X, not PCIe, so having something PCIe-specific
> is not a solution for this case; and
> b) the PCIe behavior is opt-in, in the sense that you have to
> specifically ask for looser ordering, while the Altix is loosely
> ordered unless you ask for this "flush" property. So I don't
> think the same attribute will work for both cases.
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.
I agree the altix needs something, what I don't agree is that we should
be overloading the dma data direction to do it ... especially given the
confetti like shower of other bus attributes waiting in the wings.
What it wants to do is set strict ordering for the bus ... well, that is
an attribute in the PCIe standard (it just happens to be the default one
for a standard bus, whereas relaxed is the default for altix). However,
set bus attribute strict would be a simple no-op for a standard bus (and
set attribute relaxed a no-op for altix).
James
next prev parent reply other threads:[~2008-01-08 18:22 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-08 2:32 [RFC/PARTIAL PATCH 0/3] dma: passing "attributes" to dma_map_* routines akepner
2008-01-08 16:27 ` James Bottomley
2008-01-08 17:42 ` Roland Dreier
2008-01-08 17:54 ` James Bottomley
2008-01-08 18:05 ` Roland Dreier
2008-01-08 18:21 ` James Bottomley [this message]
2008-01-09 0:55 ` akepner
2008-01-09 21:00 ` Roland Dreier
2008-01-09 21:05 ` akepner
2008-01-09 21:30 ` James Bottomley
2008-01-11 18:20 ` Grant Grundler
2008-01-08 18:13 ` akepner
2008-01-08 17:50 ` Christoph Hellwig
2008-01-08 17:55 ` Roland Dreier
2008-01-08 18: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=1199816504.3534.59.camel@localhost.localdomain \
--to=james.bottomley@hansenpartnership.com \
--cc=akepner@sgi.com \
--cc=davem@davemloft.net \
--cc=grundler@parisc-linux.org \
--cc=jbarnes@virtuousgeek.org \
--cc=jes@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=muli@il.ibm.com \
--cc=randy.dunlap@oracle.com \
--cc=rdreier@cisco.com \
--cc=tony.luck@intel.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