[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9160031b-50be-6993-5a8e-f238391962c5@huawei.com>
Date: Tue, 17 May 2022 12:26:21 +0100
From: John Garry <john.garry@...wei.com>
To: Robin Murphy <robin.murphy@....com>, <joro@...tes.org>,
<will@...nel.org>, <hch@....de>, <m.szyprowski@...sung.com>
CC: <chenxiang66@...ilicon.com>, <thunder.leizhen@...wei.com>,
<iommu@...ts.linux-foundation.org>, <linux-kernel@...r.kernel.org>,
<liyihang6@...ilicon.com>
Subject: Re: [RFC PATCH] dma-iommu: Add iommu_dma_max_mapping_size()
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@...wei.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
Powered by blists - more mailing lists