Re: libata+SGIO: is .dma_boundary respected?

[Mark Lord <liml@rtr.ca>]

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