From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 21723C433EF for ; Tue, 17 May 2022 09:02:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243934AbiEQJCL (ORCPT ); Tue, 17 May 2022 05:02:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48160 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238173AbiEQJCF (ORCPT ); Tue, 17 May 2022 05:02:05 -0400 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C8CFC1AD85 for ; Tue, 17 May 2022 02:02:03 -0700 (PDT) Received: from fraeml710-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4L2VR854Wrz67L0F; Tue, 17 May 2022 16:59:00 +0800 (CST) Received: from lhreml724-chm.china.huawei.com (10.201.108.75) by fraeml710-chm.china.huawei.com (10.206.15.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 17 May 2022 11:02:01 +0200 Received: from [10.47.88.19] (10.47.88.19) by lhreml724-chm.china.huawei.com (10.201.108.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 17 May 2022 10:02:00 +0100 Message-ID: <3e7c4d27-a0cb-2d9e-ca79-248ce26c6787@huawei.com> Date: Tue, 17 May 2022 10:02:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [RFC PATCH] dma-iommu: Add iommu_dma_max_mapping_size() To: Christoph Hellwig CC: , , , , , , , , References: <1652706361-92557-1-git-send-email-john.garry@huawei.com> <20220517083834.GA16965@lst.de> From: John Garry In-Reply-To: <20220517083834.GA16965@lst.de> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.47.88.19] X-ClientProxiedBy: lhreml743-chm.china.huawei.com (10.201.108.193) To lhreml724-chm.china.huawei.com (10.201.108.75) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 17/05/2022 09:38, Christoph Hellwig wrote: > On Mon, May 16, 2022 at 09:06:01PM +0800, 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. BTW, on a separate topic, I noticed that even with this change my ATA devices have max_hw_sectors_kb of 32767, as opposed to 128 for SAS devices. It seems that libata-scsi - specifically ata_scsi_dev_config() - doesn't honour the shost max_sectors limit. I guess that is not intentional. >> >> [0] https://lore.kernel.org/linux-iommu/20210129092120.1482-1-thunder.leizhen@huawei.com/ >> >> Signed-off-by: John Garry >> --- >> 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 >> >> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c >> index 09f6e1c0f9c0..e2d5205cde37 100644 >> --- a/drivers/iommu/dma-iommu.c >> +++ b/drivers/iommu/dma-iommu.c >> @@ -1442,6 +1442,21 @@ static unsigned long iommu_dma_get_merge_boundary(struct device *dev) >> return (1UL << __ffs(domain->pgsize_bitmap)) - 1; >> } >> > >> + if (!domain) >> + return 0; >> + >> + cookie = domain->iova_cookie; >> + if (!cookie || cookie->type != IOMMU_DMA_IOVA_COOKIE) >> + return 0; > > Can these conditions even be true here? I don't think so. Paranoia on my part. > >> +static inline unsigned long iova_rcache_range(void) >> +{ >> + return 0; >> +} > > Given that IOMMU_DMA select IOMMU_IOVA there is no need for this stub. hmmm.. ok. Policy was to be stub everything but I think that it has changed. > > Otherwise this looks sensible to me. > > . Great, thanks.