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, 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 bus that
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
> 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 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 device
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 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 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
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
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.
--
> > 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
> 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
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
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:
>
> 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,
>
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,
most
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, 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:
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).
I
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
anything
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
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
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
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, 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
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=119258541412724=2.)
This is incomplete in that only ia64
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-kernelm=119258541412724w=2.)
This is incomplete in that only ia64
30 matches
Mail list logo
