From: Matthew Wilcox <matthew@wil.cx>
To: Yu Zhao <yu.zhao@intel.com>
Cc: jbarnes@virtuousgeek.org, dwmw2@infradead.org,
linux-pci@vger.kernel.org, iommu@lists.linux-foundation.org,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/6] PCI: support the ATS capability
Date: Wed, 11 Feb 2009 10:38:38 -0700 [thread overview]
Message-ID: <20090211173838.GC3624@parisc-linux.org> (raw)
In-Reply-To: <1232252254-7614-2-git-send-email-yu.zhao@intel.com>
On Sun, Jan 18, 2009 at 12:17:29PM +0800, Yu Zhao wrote:
> +/**
> + * pci_ats_qdep - query ATS invalidate queue depth
> + * @dev: the PCI device
> + *
> + * Returns the queue depth on success, or 0 on error.
> + */
> +int pci_ats_qdep(struct pci_dev *dev)
> +{
> + int pos;
> + u16 cap;
> +
> + pos = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_ATS);
> + if (!pos)
> + return 0;
> +
> + pci_read_config_word(dev, pos + PCI_ATS_CAP, &cap);
> +
> + return PCI_ATS_CAP_QDEP(cap) ? : PCI_ATS_MAX_QDEP;
> +}
The only concern I have with this patch is that every time we enable,
disable or call qdep (ok, maybe I have a second problem with 'qdep'
instead of spelling out 'queue_depth'), we call
pci_find_ext_capability() which is not necessarily cheap. I can't tell
from this series of patches whether this is a real performance problem
or whether we ask for the qdep once per device per boot.
There was a performance problem with the MSI code when it would try to
pci_find_capability() the MSI cap in the interrupt handler. This was
fixed long ago by caching the pos of the cap, so I want to be sure we're
not making the same mistake again here.
Hm, a third problem is that the empty ? : is really confusing and
generally to be avoided. GCC should be able to figure out that it's a
pure/const function anyway and avoid recalculating it.
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
next prev parent reply other threads:[~2009-02-11 17:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-18 4:17 [PATCH v2 0/6] ATS capability support for Intel IOMMU Yu Zhao
2009-01-18 4:17 ` [PATCH v2 1/6] PCI: support the ATS capability Yu Zhao
2009-02-10 11:32 ` David Woodhouse
2009-02-11 17:33 ` Jesse Barnes
2009-02-11 17:38 ` Matthew Wilcox [this message]
2009-01-18 4:17 ` [PATCH v2 2/6] VT-d: parse ATSR in DMA Remapping Reporting Structure Yu Zhao
2009-01-18 4:17 ` [PATCH v2 3/6] VT-d: add queue invalidation fault status support Yu Zhao
2009-01-18 4:17 ` [PATCH v2 4/6] VT-d: add device IOTLB invalidation support Yu Zhao
2009-01-18 4:17 ` [PATCH v2 5/6] VT-d: cleanup iommu_flush_iotlb_psi and flush_unmaps Yu Zhao
2009-01-18 4:17 ` [PATCH v2 6/6] VT-d: support the device IOTLB Yu Zhao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090211173838.GC3624@parisc-linux.org \
--to=matthew@wil.cx \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=jbarnes@virtuousgeek.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=yu.zhao@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.