linux-kernel - Re: [RFC/PARTIAL PATCH 0/3] dma: passing "attributes" to dma_map

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1199816504.3534.59.camel@localhost.localdomain>
Date:	Tue, 08 Jan 2008 12:21:44 -0600
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Roland Dreier <rdreier@...co.com>
Cc:	akepner@....com, Tony Luck <tony.luck@...el.com>,
	Grant Grundler <grundler@...isc-linux.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Jes Sorensen <jes@....com>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	David Miller <davem@...emloft.net>,
	Muli Ben-Yehuda <muli@...ibm.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC/PARTIAL PATCH 0/3] dma: passing "attributes" to dma_map_*
	routines


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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/