Re: libata+SGIO: is .dma_boundary respected?

[Jeff Garzik <jgarzik@pobox.com>]

Mark Lord wrote:
> Jens Axboe wrote:
> ..
> 
>> Seems to me that your reasoning is correct. It's a fact that the
>> original block mapped sg lists satisfies all requirements of the device
>> driver and/or hardware, otherwise would be a bug. The iommu may go nuts
>> of course, but logically that new sg list should be choppable into the
>> same requirements.
> 
> 
> I just finished going through all of the arch implementations and,
> as near as I can tell, they only ever *merge* sg list items,
> and never create additional sg entries.
> 
> So low-level drivers (at present) can safely report their real limits,
> and then in their fill_sg() routines they can run around and split up
> any IOMMU merges that their hardware cannot tolerate.

I remain highly skeptical, and would be interested to see James and Ben 
weight in on the subject, as they were the key iommu vmerge people 
around the time libata ata_fill_sg() was originally written (and fixed 
by BenH).


>> It would be much nicer if the iommu actually had some more knowledge,
>> ideally the same requirements that the block layer is faced with. No
>> driver should have to check the mapped sg list.


> Yup.  Absolutely.  So long as they continue to never *add* new sg entries
> (only doing merges instead), then I believe they just need to know the
> device's .dma_boundary parameter.  We could pass this to them as an extra
> parameters, or perhaps embed it into the sg_list data structure somehow.
> 
> In the case of sata_mv on the Marvell 6081 (which I'm looking at this week)
> it's hardware limit is actually 0xffffffff rather than 0xffff.

If the limit is not 0xffff, then there's no need for any of this 
limitation junk.  No s/g entry splitting after pci_map_sg(), no 
artificial sg_tablesize limitation, etc.


> I wonder how well Linux drivers in general deal with that on a 64-bit 
> machine?

Works just fine.

	Jeff