Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp215525ybm; Thu, 28 May 2020 00:34:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyHlSn2/YbcYvHPjuqepK+9ICUncSAqT43KQPFxzWT0pCDqR0FDmBfTbCSKS6p4OoHDON6V X-Received: by 2002:a50:9e21:: with SMTP id z30mr1618372ede.347.1590651278560; Thu, 28 May 2020 00:34:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590651278; cv=none; d=google.com; s=arc-20160816; b=hGxePsU7SArhrvQvuCXhIpAOg0zjGelm9OfsyugrCbevxq7uOM84nHex+WkJjtOvcO exM1mJrGpIPJMjyl3/klirT/6DB6z22akCAuvoPLLDV8TDjBFI587/fLQVsg0P+EcOju 0QQSfleEINGkxqQJprb6q5RF00pKY2xcO8W4mOmWBclLQngpzd6ILFJa15OsU8JDtxtP 7nKpM1GioZ7LshmoT0VxY9GSwDXJ3/uKVc96n8wvL8LyxbjzbUV1nt98YpIzPbIJeW5J 8lUZl32IWzANl+zobivUO7AM9iJ+c2blVzIlbZd4GKL8hha4JHtAFleqqeHCrVwArutQ PCGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=f9iIcGmhEf/upaEwaUkrOZGcNGGtM50NCo8CHnB19ms=; b=BRmkeeG5sEJGvA7RS1AnhOLZUBg6e0CAnY56thKo1qhXqpjVagTuYdlJG6Z8Scwf+b CRDbbbmHVJk5mW2AZKaqtKjaGqyht+lLYe/ZSYUXD/2+n8eQIujA2/PYyCURfp4KxBEk 6Y1gQfAqxD9C8yUppVp188Ro2XE5JRKMz96lPn7v9wtCq8ekaXEobDu6yvQCgteRXU04 azfIZsPPVX9CReLzw23b+Fp/wxnEH0S/FXE0KBag1doaV8pwvCJAEdTy4XDlbrUQ4Z4t mo1a8LSQUAp8MQb1oOrgl79iobqe2ckaWm3n47cgv9jmizA3WFdsdQe0tjtF6weZsU9b 8svQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j24si3364944ejd.160.2020.05.28.00.34.10; Thu, 28 May 2020 00:34:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726446AbgE1Hdu (ORCPT + 99 others); Thu, 28 May 2020 03:33:50 -0400 Received: from 8bytes.org ([81.169.241.247]:45176 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725882AbgE1Hdu (ORCPT ); Thu, 28 May 2020 03:33:50 -0400 Received: by theia.8bytes.org (Postfix, from userid 1000) id B776F327; Thu, 28 May 2020 09:33:45 +0200 (CEST) Date: Thu, 28 May 2020 09:33:44 +0200 From: Joerg Roedel To: Bjorn Helgaas Cc: Zhangfei Gao , Bjorn Helgaas , Arnd Bergmann , Lorenzo Pieralisi , Hanjun Guo , Sudeep Holla , "Rafael J. Wysocki" , Len Brown , jean-philippe , Greg Kroah-Hartman , Herbert Xu , kenneth-lee-2012@foxmail.com, Wangzhou , linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, iommu@lists.linux-foundation.org, linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org Subject: Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU Message-ID: <20200528073344.GO5221@8bytes.org> References: <1590493749-13823-1-git-send-email-zhangfei.gao@linaro.org> <20200527181842.GA256680@bjorn-Precision-5520> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200527181842.GA256680@bjorn-Precision-5520> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Wed, May 27, 2020 at 01:18:42PM -0500, Bjorn Helgaas wrote: > Is this slowdown significant? We already iterate over every device > when applying PCI_FIXUP_FINAL quirks, so if we used the existing > PCI_FIXUP_FINAL, we wouldn't be adding a new loop. We would only be > adding two more iterations to the loop in pci_do_fixups() that tries > to match quirks against the current device. I doubt that would be a > measurable slowdown. I don't know how significant it is, but I remember people complaining about adding new PCI quirks because it takes too long for them to run them all. That was in the discussion about the quirk disabling ATS on AMD Stoney systems. So it probably depends on how many PCI devices are in the system whether it causes any measureable slowdown. Regards, Joerg