All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Aaron Lewis <aaronlewis@google.com>
Cc: alex.williamson@redhat.com, dmatlack@google.com,
	kvm@vger.kernel.org, seanjc@google.com
Subject: Re: [RFC PATCH 0/2] vfio: Improve DMA mapping performance for huge pages
Date: Tue, 23 Dec 2025 22:04:21 -0400	[thread overview]
Message-ID: <aUtKJbvsQNANXjO/@nvidia.com> (raw)
In-Reply-To: <20251223230044.2617028-1-aaronlewis@google.com>

On Tue, Dec 23, 2025 at 11:00:42PM +0000, Aaron Lewis wrote:
> This RFC explores the current state of DMA mapping performance across
> vfio, and proposes an implementation to improve the performance
> for "vfio_type1_iommu" for huge pages.

We are trying to sunset type1, please just use the memfd path on
iommufd which is supposed to be the fastest available option. You can
try to improve iommufd as well.

But we definately should not be making type 1 the best option and then
encouraging people to use it - that is the opposite of what we are
trying to do!

> This is being sent as an RFC because while there is a proposed solution
> for "vfio_type1_iommu", there are no solutions for the other two iommu
> modes.  Attached is a callstack in patch 1/2 showing where the latency
> issues are for iommufd, however, I haven't posted one
> for "iommufd_compat_type1". I'm also not clear on what the intention is
> for "iommufd_compat_type1" w.r.t. this issue.  Especially given it is so
> much slower than the others.

Probably your test is using VFIO_TYPE1_IOMMU for iommufd and comparing
it to VFIO_TYPE1v2_IOMMU for vfio. v0 forces 4k pages at the iommu
domain which is much slower.

It is also really weird because I have seen other people reporting a
30x speedup using iommufd and here you are reporting it is the slowest
option?

Jason

      parent reply	other threads:[~2025-12-24  2:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-23 23:00 [RFC PATCH 0/2] vfio: Improve DMA mapping performance for huge pages Aaron Lewis
2025-12-23 23:00 ` [RFC PATCH 1/2] " Aaron Lewis
2025-12-24  2:10   ` Jason Gunthorpe
2025-12-29 21:40     ` Aaron Lewis
2025-12-30  1:12       ` Jason Gunthorpe
2026-01-05 18:31         ` David Matlack
2026-01-05 19:01           ` Jason Gunthorpe
2026-01-05 19:36             ` David Matlack
2025-12-23 23:00 ` [RFC PATCH 2/2] vfio: selftest: Add vfio_dma_mapping_perf_test Aaron Lewis
2025-12-24  2:04 ` Jason Gunthorpe [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=aUtKJbvsQNANXjO/@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=aaronlewis@google.com \
    --cc=alex.williamson@redhat.com \
    --cc=dmatlack@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=seanjc@google.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.