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 X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BD199C433E0 for ; Fri, 31 Jul 2020 12:32:24 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 86B50206FA for ; Fri, 31 Jul 2020 12:32:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="gubNxZs7" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 86B50206FA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=hisilicon.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:In-Reply-To:References:Message-ID:Date: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=UVyluJNOSo9pDIS5ao3lRNjO6A6WiNHoSzlmeulSoFg=; b=gubNxZs70GdklRw7hFIWn/ciX rdSzL9QtySGUYYEal7A+wkZMreEvhaSyRSGkfMxvSZq476BPTUPiqhrEKFYrcYqek5HPBGiTZtGt8 PG9dLEcWBEQg705Htj2mi1ksUf/yPL/pRta1nj+YudWcBHZIL9pRZjvFfuzIzBmn6gIPkADG7apxj M5rmHQ8N8deCjdbM5dF0ckogPxBEGUpBnAUrU6AFpok5TFlaIJrQUhAsxDEz0gTidHz+V8XFaoCXm iq7zHyyrg6UfUTzEVt+Z1UlUnp3qsqzTpukYYJjN6+sj7+WXDLouk/bRZSvXd030mijDAUhrTYClF b3SRfSLkg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k1UBP-0005jo-ME; Fri, 31 Jul 2020 12:30:43 +0000 Received: from szxga01-in.huawei.com ([45.249.212.187] helo=huawei.com) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k1UBM-0005id-3v for linux-arm-kernel@lists.infradead.org; Fri, 31 Jul 2020 12:30:41 +0000 Received: from dggemi404-hub.china.huawei.com (unknown [172.30.72.54]) by Forcepoint Email with ESMTP id CB381A90D0710C76F342; Fri, 31 Jul 2020 20:30:34 +0800 (CST) Received: from DGGEMI525-MBS.china.huawei.com ([169.254.6.120]) by dggemi404-hub.china.huawei.com ([10.3.17.142]) with mapi id 14.03.0487.000; Fri, 31 Jul 2020 20:30:27 +0800 From: "Song Bao Hua (Barry Song)" To: Will Deacon Subject: RE: [PATCH v2] iommu/arm-smmu-v3: disable MSI polling if SEV polling is faster Thread-Topic: [PATCH v2] iommu/arm-smmu-v3: disable MSI polling if SEV polling is faster Thread-Index: AQHWZxWmNQkz6uwX10qDXyIfMcuen6kg9FsAgACJfxD//5gzAIAAhubA Date: Fri, 31 Jul 2020 12:30:27 +0000 Message-ID: References: <20200731083343.18152-1-song.bao.hua@hisilicon.com> <20200731122149.GA26817@willie-the-truck> In-Reply-To: <20200731122149.GA26817@willie-the-truck> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.126.201.221] MIME-Version: 1.0 X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200731_083040_460379_984245BD X-CRM114-Status: GOOD ( 32.74 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "joro@8bytes.org" , John Garry , Linuxarm , "iommu@lists.linux-foundation.org" , "Zengtao \(B\)" , "robin.murphy@arm.com" , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org > -----Original Message----- > From: Will Deacon [mailto:will@kernel.org] > Sent: Saturday, August 1, 2020 12:22 AM > To: Song Bao Hua (Barry Song) > Cc: John Garry ; robin.murphy@arm.com; > joro@8bytes.org; iommu@lists.linux-foundation.org; Zengtao (B) > ; Linuxarm ; > linux-arm-kernel@lists.infradead.org > Subject: Re: [PATCH v2] iommu/arm-smmu-v3: disable MSI polling if SEV > polling is faster > > On Fri, Jul 31, 2020 at 10:48:33AM +0000, Song Bao Hua (Barry Song) wrote: > > > -----Original Message----- > > > From: John Garry > > > Sent: Friday, July 31, 2020 10:21 PM > > > To: Song Bao Hua (Barry Song) ; > will@kernel.org; > > > robin.murphy@arm.com; joro@8bytes.org; > iommu@lists.linux-foundation.org > > > Cc: Zengtao (B) ; Linuxarm > > > ; linux-arm-kernel@lists.infradead.org > > > Subject: Re: [PATCH v2] iommu/arm-smmu-v3: disable MSI polling if SEV > > > polling is faster > > > > > > On 31/07/2020 09:33, Barry Song wrote: > > > > Different implementations may show different performance by using SEV > > > > polling or MSI polling. > > > > On the implementation of hi1620, tests show disabling MSI polling can > > > > bring performance improvement. > > > > Using 16 threads to run netperf on hns3 100G NIC with UDP packet size > > > > in 32768bytes and set iommu to strict, TX throughput can improve from > > > > 25Gbps to 27Gbps by this patch. > > > > This patch adds a generic function to support implementation options > > > > based on IIDR and disables MSI polling if IIDR matches the specific > > > > implementation tested. > > > Not sure if we should do checks like this on an implementation basis. > > > I'm sure maintainers will decide. > > > > Yes, maintainers will decide. I guess Will won't object to IIDR-based solution > according to > > previous discussion threads: > > https://lore.kernel.org/patchwork/patch/783718/ > > > > Am I right, Will? > > Honestly, I object to the whole idea that we should turn off optional > hardware features just because they're slow. Did nobody take time to look at > the design and check that it offered some benefit, or where they in too much > of a hurry to tick the checkbox to say they had the new feature? I really > dislike the pick and mix nature that some of this IP is heading in, where > the marketing folks want a slice of everything for the branding, instead of > doing a few useful things well. Anyway, that's not your fault, so I'll stop > moaning. *sigh* > > Given that you've baked this thing now, then if we have to support it I > would prefer the command-line option. At least that means that people can > compare the performance with it on and off (and hopefully make sure the > hardware doesn't suck). It also means it's not specific to ACPI. Hi Will, Thanks for your comment. I had a patch with command line option as below. If it is what you prefer, I'd refine this one and send. [PATCH] iommu/arm-smmu-v3: permit users to disable msi polling --- drivers/iommu/arm-smmu-v3.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c index f578677a5c41..4fb1681308e4 100644 --- a/drivers/iommu/arm-smmu-v3.c +++ b/drivers/iommu/arm-smmu-v3.c @@ -418,6 +418,11 @@ module_param_named(disable_bypass, disable_bypass, bool, S_IRUGO); MODULE_PARM_DESC(disable_bypass, "Disable bypass streams such that incoming transactions from devices that are not attached to an iommu domain will report an abort back to the device and will not be allowed to pass through the SMMU."); +static bool disable_msipolling = 1; +module_param_named(disable_msipolling, disable_msipolling, bool, S_IRUGO); +MODULE_PARM_DESC(disable_msipolling, + "Don't use MSI to poll the completion of CMD_SYNC if it is slower than SEV"); + enum pri_resp { PRI_RESP_DENY = 0, PRI_RESP_FAIL = 1, @@ -992,7 +997,7 @@ static void arm_smmu_cmdq_build_sync_cmd(u64 *cmd, struct arm_smmu_device *smmu, * Beware that Hi16xx adds an extra 32 bits of goodness to its MSI * payload, so the write will zero the entire command on that platform. */ - if (smmu->features & ARM_SMMU_FEAT_MSI && + if (!disable_msipolling && smmu->features & ARM_SMMU_FEAT_MSI && smmu->features & ARM_SMMU_FEAT_COHERENCY) { ent.sync.msiaddr = q->base_dma + Q_IDX(&q->llq, prod) * q->ent_dwords * 8; @@ -1332,7 +1337,7 @@ static int __arm_smmu_cmdq_poll_until_consumed(struct arm_smmu_device *smmu, static int arm_smmu_cmdq_poll_until_sync(struct arm_smmu_device *smmu, struct arm_smmu_ll_queue *llq) { - if (smmu->features & ARM_SMMU_FEAT_MSI && + if (!disable_msipolling && smmu->features & ARM_SMMU_FEAT_MSI && smmu->features & ARM_SMMU_FEAT_COHERENCY) return __arm_smmu_cmdq_poll_until_msi(smmu, llq); -- 2.27.0 Thanks Barry _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel