Mark Lord wrote:
Mark Lord wrote:
Jeff Garzik wrote:
The idiot IOMMU layer may merge too aggressively, which is the reason
for this code and similar code in ata_fill_sg(). The IOMMU stuff
always happens at pci_map_sg() time, after the block layer gets out
of the way.
Ahh.. then how does the low-level driver know what to use for
".sg_tablesize"?
It cannot use the real hardware/driver value, because it may need to do
request splitting. I wonder what the worst case number of splits
required
is, for each sg[] entry?
Mmmm. I suppose the answer is that the block layer guarantees
no more than .sg_tablesize entries, and the IOMMU layer may reduce
the segment count, but never increase it.
So the low-level driver should be able to safely use it's own internal
hardware/driver limit when registering .sg_tablesize.
The IOMMU layer can merge across 64k boundaries, yet still produce a
worst case s/g entry count. Thus, you wind up with sg_tablesize
entries, and splits still to be done.
That's why drivers that worry about 64k boundary have to give a false
sg_tablesize to the SCSI layer: to reserve sufficient "true" s/g entries
for the worst case IOMMU split.
Jeff
-
: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
