Re: [PATCH v2] add bidi support for block pc requests

[Jeff Garzik <jeff@garzik.org>]

James Bottomley wrote:
> On Sat, 2007-07-07 at 11:27 -0400, Jeff Garzik wrote:
>> LIBATA_MAX_PRD is the maximum number of DMA scatter/gather elements 
>> permitted by the HBA's DMA engine, for a single ATA command.

> Then it's the wrong parameter you're setting:  phys_segments is what you
> have going into a dma_map_sg() but hw_segments is what you end up after
> it (mathemtaically, the mapping never splits segments, so hw_segments <=
> phys_segments always, but it's still the wrong way to bound this); so if
> you want to limit the SG elements in the HBA, you should set hw_segments
> not phys_segments (which is what the sg_tablesize parameter of the host
> structure corresponds to).

Honestly I'm betting the code is a result of paranoia^H^H^Hconservatism 
on my part:  setting every DMA and segment limit I can find, in the 
hopes that somehow, somewhere, that information will get filtered down 
to the IOMMU and whatnot.  :)

Given what you say above, and the fact that I set sg_tablesize, 
presumably Boaz's patch to remove phys_segment limiting in libata-scsi 
is the right thing to do.  Your knowledge in this area is most likely 
stronger than mine.


> However, I suspect this has to do with our iommu problem, doesn't it?
> The IOMMU may merge the segments beyond your 64k DMA boundary, so you
> need to split them again ... in that case you need phys_segments
> bounded, not hw_segments?

This is why I set every segment limitation I could find :)  And then Ben 
tells me IOMMU may ignore all of that anyway, and so I have code to 
split inside libata as well :)

I just know what IDE needs:  S/G ent shouldn't cross 64k boundary, nor 
exceed 64k in size.  The maximum number of S/G ents is actually a guess. 
  Hard data is tough to come by.  Some DMA engines will cycle through 
all of memory until they hit a stop bit.  Others have limits yet to be 
discovered.  :)

	Jeff