Re: libata+SGIO: is .dma_boundary respected?

[Jeff Garzik <jgarzik@pobox.com>]

Mark Lord wrote:
> Jeff Garzik wrote:
> 
>> Mark Lord wrote:
>>
>>> So therefore, code to manage the dma_boundary is NOT necessary in 
>>> sata drivers. Right?  Currently we have in sata_mv.c:
>>>
>>>     MV_DMA_BOUNDARY = 0xffff;
>>>                 while (sg_len) {
>>>                         offset = addr & MV_DMA_BOUNDARY;
>>>                         len = sg_len;
>>>                         if ((offset + sg_len) > 0x10000)
>>>                                 len = 0x10000 - offset;
>>>                 ...
>>>
>>>
>>> That whole block should be able to go, then.
>>
>>
>> Incorrect.  :)
>>
>> 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?

To answer that question, you have to take into account the 64k DMA 
boundary requirement, the worst case split (==sg_tablesize), and how 
many splits required in each s/g entry -- in the case of sata_mv.c and 
ata_fill_sg(), worst case is one split per s/g entry.

	Jeff