>>>>> "David" == David S Miller <[email protected]> writes:
David> Alan Cox writes:
>> Thats something we already know has to be fixed. Its true with or
>> without an IOMMU that there may be cases where there is no free
>> mapping space
David> True, but my intended point is that starving the SAC-only users
David> then returning DAC addresses to DAC-capable devices is just as
David> unacceptable.
David> When we have one of these compute cluster cards in the box, and
David> Jes's suggested algorithm is used, the rest of the SAC devices
David> in the box would be totally screwed once the IOMMU fills up.
The dma_mask in struct pci_dev tells you whether you are DAC
capable. We pass a pointer to this struct when we call the pci_*
functions so the required information needed to make the decision
whether to return a SAC or a DAC address is already available.
Cheers
Jes
Jes Sorensen writes:
> The dma_mask in struct pci_dev tells you whether you are DAC
> capable. We pass a pointer to this struct when we call the pci_*
> functions so the required information needed to make the decision
> whether to return a SAC or a DAC address is already available.
The decision is not based upon "device capable of DAC", that is
precisely my point.
The decision must be based upon a number of considerations.
1) Can it do DAC
2) Is DAC more efficient than SAC on this platform
3) Does the devices _need_ DAC even if it is slower because
it requires referencing large portions of the DMA
address space simultaneously
Sure, you could imply all of this complexity in the driver
by making them consider all of these issues when setting the
mask, but that isn't a nice interface at all.
And this still leaves the 64-bit dma_addr_t overhead issue.
Later,
David S. Miller
[email protected]
On Thu, 5 Jul 2001, David S. Miller wrote:
> And this still leaves the 64-bit dma_addr_t overhead issue.
Huh? It's a config option, just like blkoff_t.
-ben