Messages in this thread | | | Date | Tue, 17 May 2022 12:26:21 +0100 | Subject | Re: [RFC PATCH] dma-iommu: Add iommu_dma_max_mapping_size() | From | John Garry <> |
| |
On 17/05/2022 11:40, Robin Murphy wrote: > On 2022-05-16 14:06, John Garry wrote: >> For streaming DMA mappings involving an IOMMU and whose IOVA len >> regularly >> exceeds the IOVA rcache upper limit (meaning that they are not cached), >> performance can be reduced. >> >> Add the IOMMU callback for DMA mapping API dma_max_mapping_size(), which >> allows the drivers to know the mapping limit and thus limit the requested >> IOVA lengths. >> >> This resolves the performance issue originally reported in [0] for a SCSI >> HBA driver which was regularly mapping SGLs which required IOVAs in >> excess of the IOVA caching limit. In this case the block layer limits the >> max sectors per request - as configured in __scsi_init_queue() - which >> will limit the total SGL length the driver tries to map and in turn >> limits >> IOVA lengths requested. >> >> [0] >> https://lore.kernel.org/linux-iommu/20210129092120.1482-1-thunder.leizhen@huawei.com/ >> >> >> Signed-off-by: John Garry <john.garry@huawei.com> >> --- >> Sending as an RFC as iommu_dma_max_mapping_size() is a soft limit, and >> not >> a hard limit which I expect is the semantics of >> dma_map_ops.max_mapping_size > > Indeed, sorry but NAK for this being nonsense. As I've said at least > once before, if the unnecessary SAC address allocation attempt slows > down your workload, make it not do that in the first place. If you don't > like the existing command-line parameter then fine, > there are plenty of > other options, it just needs to be done in a way that doesn't break x86 > systems with dodgy firmware, as my first attempt turned out to.
Sorry, but I am not interested in this. It was discussed in Jan last year without any viable solution.
Anyway we still have the long-term IOVA aging issue, and requesting non-cached IOVAs is involved in that. So I would rather keep the SCSI driver to requesting cached IOVAs all the time.
I did try to do it the other way around - configuring the IOVA caching range according to the drivers requirement but that got nowhere.
> > Furthermore, if a particular SCSI driver doesn't benefit from mappings > larger than 256KB, then that driver is also free to limit its own > mapping size. There are other folks out there with use-cases for mapping > *gigabytes* at once; you don't get to cripple the API and say that > that's suddenly not allowed just because it happens to make your thing > go faster, that's absurd.
I'd say less catastrophically slow, not faster.
So how to inform the SCSI driver of this caching limit then so that it may limit the SGL length?
Thanks, John
| |