All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Niklas Schnelle <schnelle@linux.ibm.com>
Cc: Robin Murphy <robin.murphy@arm.com>,
	Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
	Wenjia Zhang <wenjia@linux.ibm.com>,
	Matthew Rosato <mjrosato@linux.ibm.com>,
	Gerd Bayer <gbayer@linux.ibm.com>,
	Pierre Morel <pmorel@linux.ibm.com>,
	iommu@lists.linux.dev, linux-s390@vger.kernel.org,
	borntraeger@linux.ibm.com, hca@linux.ibm.com, gor@linux.ibm.com,
	gerald.schaefer@linux.ibm.com, agordeev@linux.ibm.com,
	svens@linux.ibm.com, linux-kernel@vger.kernel.org,
	Julian Ruess <julianr@linux.ibm.com>
Subject: Re: [PATCH v5 5/7] iommu/dma: Allow a single FQ in addition to per-CPU FQs
Date: Mon, 30 Jan 2023 12:40:08 -0400	[thread overview]
Message-ID: <Y9fy6KXdA3OqNudY@nvidia.com> (raw)
In-Reply-To: <8209c172aaa415eace9dcd4b5675ef8506a34538.camel@linux.ibm.com>

On Mon, Jan 30, 2023 at 04:57:56PM +0100, Niklas Schnelle wrote:

> I'm wondering if maybe instead of plain flag bits it makes more sense
> to have a dma_iommu_options struct that contains the queue size and a
> flags value which indicates whether a single or per-CPU queue is
> used.

Querying the driver for what kind of performance tuning it would like
to use by default makes sense to me.

> Then I could add an iommu_ops callback that takes a device and a
> pointer to the dma_iommu_options. That way we can still set the options
> per device but don't need a whole extra domain type. This callback
> would then just be called during initialization of the DMA-FQ domain
> and not having the callback just leaves the defaults unchanged. Does
> that go in the right direction?

I like it

Jason

  reply	other threads:[~2023-01-30 16:40 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-24 12:50 [PATCH v5 0/7] iommu/dma: s390 DMA API conversion and optimized IOTLB flushing Niklas Schnelle
2023-01-24 12:50 ` [PATCH v5 1/7] s390/ism: Set DMA coherent mask Niklas Schnelle
2023-01-24 12:50 ` [PATCH v5 2/7] iommu: Allow .iotlb_sync_map to fail and handle s390's -ENOMEM return Niklas Schnelle
2023-01-24 12:50 ` [PATCH v5 3/7] s390/pci: prepare is_passed_through() for dma-iommu Niklas Schnelle
2023-01-24 12:50 ` [PATCH v5 4/7] s390/pci: Use dma-iommu layer Niklas Schnelle
2023-01-24 12:50 ` [PATCH v5 5/7] iommu/dma: Allow a single FQ in addition to per-CPU FQs Niklas Schnelle
2023-01-30 15:13   ` Robin Murphy
2023-01-30 15:29     ` Jason Gunthorpe
2023-01-30 15:57       ` Niklas Schnelle
2023-01-30 16:40         ` Jason Gunthorpe [this message]
2023-01-30 15:36     ` Niklas Schnelle
2023-01-24 12:50 ` [PATCH v5 6/7] iommu/dma: Enable variable queue size and use larger single queue Niklas Schnelle
2023-01-24 12:50 ` [PATCH v5 7/7] iommu/dma: Add IOMMU op to choose lazy domain type Niklas Schnelle

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=Y9fy6KXdA3OqNudY@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=agordeev@linux.ibm.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=gbayer@linux.ibm.com \
    --cc=gerald.schaefer@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=julianr@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mjrosato@linux.ibm.com \
    --cc=pmorel@linux.ibm.com \
    --cc=robin.murphy@arm.com \
    --cc=schnelle@linux.ibm.com \
    --cc=svens@linux.ibm.com \
    --cc=wenjia@linux.ibm.com \
    --cc=will@kernel.org \
    /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.