Re: libata+SGIO: is .dma_boundary respected?

[Jens Axboe <axboe@suse.de>]

On Tue, Mar 21 2006, 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.

Definitely, it would be highly illegal for the iommu code to do that.
And pretty odd, too :-)

> >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.

You want max size as well, so boundary and max size should be enough.

> 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.
> 
> I wonder how well Linux drivers in general deal with that on a 64-bit 
> machine?

0xffffffff is the default boundary exactly because we assume (based on
experience and real hardware, aic7xxx springs to mind) that most
hardware cannot deal with a 4GB wrap.

-- 
Jens Axboe