Re: libata+SGIO: is .dma_boundary respected?

[Jeff Garzik <jgarzik@pobox.com>]

Mark Lord wrote:
> Jeff Garzik wrote:
> 
>> Mark Lord wrote:
>>
>>> Jens / Jeff,
>>>
>>> Each libata driver registers a .dma_boundary field with SCSI.
>>> This field is used to prevent merging of bio segments across
>>> a hardware limitation boundary, usually 0xffff.
>>>
>>> This looks like it works for regular block I/O,
>>> but I'm not so sure about SGIO originated requests.
>>>
>>> Any thoughts, or code you can point me to?
>>
>>
>> Everything goes through the block layer, including SG_IO, so everyone 
>> agrees on the boundaries that must be respected.
>>
>> scsi sets blk_queue_segment_boundary() then gets out of the way, for 
>> the most part.  BIOVEC_SEG_BOUNDARY() is the macro that accesses this. 
>> Trace back and forth from there.  You will probably run into a call to 
>> blk_recount_segments() in __bio_add_page(), or maybe you'll check the 
>> seg boundary from another path.
> 
> 
> Yeah, I'm familiar with that part, and thanks for the note about SGIO.
> 
> 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.

	Jeff