Jeff Garzik wrote:
Mark Lord wrote:
..
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.
But what is the worst case? What's to stop the IOMMU layer from merging,
say, thirty 64KB segments into a single SG entry. And then doing that
several times.. nothing.
But (as I replied to myself earlier), I think it is a non issue,
because the IOMMU merging cannot produce more SG entries than
there were originally. It may produce less, and the driver may then
end up splitting them apart again, but it will never exceed what
the block layer permitted in the first place.
So, I think that means the driver can report the real SG tablesize,
and not worry about divide-by-??? margins.
Cheers
-
: 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
