From: Peter Xu <peterx@redhat.com>
To: "Eugenio Pérez" <eperezma@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Yan Zhao <yan.y.zhao@intel.com>,
Eduardo Habkost <ehabkost@redhat.com>,
Juan Quintela <quintela@redhat.com>,
Jason Wang <jasowang@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
qemu-devel@nongnu.org, Eric Auger <eric.auger@redhat.com>,
qemu-arm@nongnu.org, Avi Kivity <avi@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [RFC v5 3/3] intel_iommu: Do not notify regular iotlb to device-iotlb notifiers
Date: Mon, 24 Aug 2020 12:20:45 -0400 [thread overview]
Message-ID: <20200824162045.GA6424@xz-x1> (raw)
In-Reply-To: <20200824104738.20664-4-eperezma@redhat.com>
On Mon, Aug 24, 2020 at 12:47:38PM +0200, Eugenio Pérez wrote:
> This improves performance in case of netperf with vhost-net:
> * TCP_STREAM: From 1374.81Mbit/s to 1845Mbit/s (37%)
> * TCP_RR: From 6559.36 trans/s to 7916.29/s (21%)
> * UDP_RR: From 6705.39 trans/s to 8199.39/s (22%)
> * UDP_STREAM: No change observed (not significant 0.1% improvement)
Good to know that we can get such a perf boost by removing the extra
invalidations!
>
> Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
> ---
> hw/i386/intel_iommu.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> index 2ad6b9d796..d539a9f281 100644
> --- a/hw/i386/intel_iommu.c
> +++ b/hw/i386/intel_iommu.c
> @@ -1959,6 +1959,12 @@ static void vtd_iotlb_domain_invalidate(IntelIOMMUState *s, uint16_t domain_id)
> vtd_iommu_unlock(s);
>
> QLIST_FOREACH(vtd_as, &s->vtd_as_with_notifiers, next) {
> + if (vtd_as->iommu.iommu_notify_flags & IOMMU_NOTIFIER_DEVIOTLB) {
> + /* If IOMMU memory region is DEVICE IOTLB type, it does not make
> + * sense to send regular IOMMU notifications. */
> + continue;
> + }
Though here IMHO a cleaner approach (rather than checking explicitly against
DEVIOTLB flag) is to add a notification type into IOMMUTLBEntry.
Then for domain invalidation, the caller is responsible to pass the type
IOMMU_NOTIFIER_UNMAP into the type field. memory_region_notify_iommu_one() will
automatically skip the message if not registerd by the notifier.
Also, it would be nice to have this new type before or when introducing the
DEVIOTLB message, otherwise the DEVIOTLB patch can be still slightly confusing
by itself when notified as UNMAP.
So here's some patch layout I'm thinking:
- patch 1: rename function, we can keep it
- patch 2: introduce "type" for IOMMUTLBEntry, so far we only have MAP/UNMAP.
Modify all callers of memory_region_notify_iommu*() to fill in the type
correctly into IOMMUTLBEntry with map/unmap. Won't hurt if we still keep
filling in UNMAP even for DEVIOTLB since that's after all the same old
behavior.
- patch 3: introduce DEVIOTLB, switch the type field of dev-iotlb
notifications to the new type and let vhost registers only to that.
- patch 4: at last, fix the assertion since we've got the DEVIOTLB messages.
Would this be slightly cleaner?
Thanks,
--
Peter Xu
prev parent reply other threads:[~2020-08-24 16:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-24 10:47 [RFC v5 0/3] memory: Delete assertion in memory_region_unregister_iommu_notifier Eugenio Pérez
2020-08-24 10:47 ` [RFC v5 1/3] memory: Rename memory_region_notify_one to memory_region_notify_iommu_one Eugenio Pérez
2020-08-24 10:47 ` [RFC v5 2/3] memory: Skip bad range assertion if notifier is DEVIOTLB type Eugenio Pérez
2020-08-24 10:47 ` [RFC v5 3/3] intel_iommu: Do not notify regular iotlb to device-iotlb notifiers Eugenio Pérez
2020-08-24 16:20 ` Peter Xu [this message]
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=20200824162045.GA6424@xz-x1 \
--to=peterx@redhat.com \
--cc=avi@redhat.com \
--cc=ehabkost@redhat.com \
--cc=eperezma@redhat.com \
--cc=eric.auger@redhat.com \
--cc=jasowang@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=rth@twiddle.net \
--cc=yan.y.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).