Re: libata+SGIO: is .dma_boundary respected?

[Jeff Garzik <jgarzik@pobox.com>]

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