Re: IOMMU and scatterlist limits

[Pierre Ossman]

Tejun Heo wrote:
> Pierre Ossman wrote:
>>
>> I'm still a bit confused why the block layer needs to know the maximum
>> number of hw segments. Different hardware might be connected to
>> different IOMMU:s, so only the driver will now how much the number can
>> be reduced. So the block layer should only care about not going above
>> max_phys_segments, since that's what the driver has room for.
>>
>> What is the scenario that requires both?
>>
>
> Let's say there is a piece of (crap) controller which can handle 4
> segments; but the system has a powerful IOMMU which can merge pretty
> well.  The driver wants to handle large requests for performance but
> it doesn't want to break up requests itself (pretty pointless, block
> layer merges, driver breaks down).  A request should be large but not
> larger than what the hardware can take at once.
>
> So, it uses max_phys_segments to tell block layer how many sg entries
> the driver is willing to handle (some arbitrary large number) and
> reports 4 for max_hw_segments letting block layer know that requests
> should not be more than 4 segments after DMA-mapping.
>
> To sum up, block layer performs request sizing in favor of block
> drivers, so it needs to know the size limits.
>
> Is this explanation any better than my previous one?  :-P
>
> Also, theoretically there can be more than one IOMMUs on a system (is
> there already?).  Block layer isn't yet ready to handle such cases but
> when it becomes necessary, all that needed is to make currently global
> IOMMU merging parameters request queue specific and modify drivers
> such that they tell block layer their IOMMU parameters.
>

Ahh. I thought the block layer wasn't aware of any IOMMU. Since I saw
those as bus specific I figured only the DMA APIs, which have access to
the device object, could know which IOMMU was to be used and how it
would merge segments.

So in my case I'll have to lie to the block layer. Iterating in the
driver will be much faster than having to do an entire new transfer.

Thanks for clearing things up. :)

Rgds
Pierre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/