On Wed, Jan 09, 2008 at 03:30:58PM -0600, James Bottomley wrote:
...
> > Also, all of this is quite separate from the PCIe "loose ordering"
> > stuff. In fact, it's quite conceivable that SGI could hook up a PCIe
> > 3.0 host bridge to the Altix NUMA interconnect, so that you could have
> > a PCI
On Wed, 2008-01-09 at 13:00 -0800, Roland Dreier wrote:
> > 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
On Wed, Jan 09, 2008 at 01:00:38PM -0800, Roland Dreier wrote:
> .
> The reason this hasn't been an issue until now is that almost all
> drivers work correctly if the Altix code just sets the "flush" bit for
> memory allocated via the consistent/coherent allocators. However, if
> we want the d
> 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
On Tue, Jan 08, 2008 at 12:21:44PM -0600, James Bottomley wrote:
> ...
> 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.
>
When you say that Altix does "som
On Tue, Jan 08, 2008 at 05:50:54PM +, Christoph Hellwig wrote:
> ...
> Onething I've missed with these patches is drivers actually using
> it. What driver actually needs it and why don't you send patches
> for them?
Some IB drivers need this. Here's an example with the ib_mthca
driver.
--
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'v
On Tue, Jan 08, 2008 at 10:27:08AM -0600, James Bottomley wrote:
> All of the attributes I can see adding are
> bus specific (even to the extent that PCIe ones wouldn't apply to PCI
> for instance)
>
The attribute I want to pass isn't bus-specific, but architecture-
specific.
--
Arthur
> > 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 matte
> Onething I've missed with these patches is drivers actually using
> it. What driver actually needs it and why don't you send patches
> for them?
In previous patch series, Arthur sent fixes for the mthca IB driver.
Other IB drivers like mlx4 also need this on Altix systems. Basically
anythin
On Tue, 2008-01-08 at 09:42 -0800, Roland Dreier wrote:
> > I'm already on record saying I don't think attributes in the generic
> > code is the right approach. All of the attributes I can see adding are
> > bus specific (even to the extent that PCIe ones wouldn't apply to PCI
> > for instance
On Mon, Jan 07, 2008 at 06:32:22PM -0800, [EMAIL PROTECTED] wrote:
>
> The following patchset allows additional "attributes" to be
> passed to dma_map_*/dma_unmap_* implementations. (The reason
> why this is useful/necessary has been mentioned several times,
> most recently here:
> http://marc.
> I'm already on record saying I don't think attributes in the generic
> code is the right approach. All of the attributes I can see adding are
> bus specific (even to the extent that PCIe ones wouldn't apply to PCI
> for instance).
I think the case before us that Arthur is dealing with is a
On Mon, 2008-01-07 at 21:32 -0500, [EMAIL PROTECTED] wrote:
> The following patchset allows additional "attributes" to be
> passed to dma_map_*/dma_unmap_* implementations. (The reason
> why this is useful/necessary has been mentioned several
> times,
> mo
The following patchset allows additional "attributes" to be
passed to dma_map_*/dma_unmap_* implementations. (The reason
why this is useful/necessary has been mentioned several times,
most recently here:
http://marc.info/?l=linux-kernel&m=119258541412724&w=2.)
This is incomplete in that only i
15 matches
Mail list logo
