archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <>
To: Robin Murphy <>
Cc: Yoshihiro Shimoda <>,,,,,,,,
Subject: Re: [RFC PATCH v5 3/8] iommu: add a new capable IOMMU_CAP_MERGING
Date: Wed, 5 Jun 2019 14:38:08 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, Jun 05, 2019 at 01:21:59PM +0100, Robin Murphy wrote:
> And if the problem is really that you're not getting merging because of 
> exposing the wrong parameters to the DMA API and/or the block layer, or 
> that you just can't quite express your requirement to the block layer in 
> the first place, then that should really be tackled at the source rather 
> than worked around further down in the stack.

The problem is that we need a way to communicate to the block layer
that more than a single segment is ok IFF the DMA API instance supports
merging.  And of course the answer will depend on futher parameters
like the maximum merged segment size and alignment for the segement.

We'll need some way to communicate that, but I don't really think this
is series is the way to go.

We'd really need something hanging off the device (or through a query
API) how the dma map ops implementation exposes under what circumstances
it can merge.  The driver can then communicate that to the block layer
so that the block layer doesn't split requests up when reaching the
segement limit.

  reply	other threads:[~2019-06-05 12:38 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-05 11:11 [RFC PATCH v5 0/8] treewide: improve R-Car SDHI performance Yoshihiro Shimoda
2019-06-05 11:11 ` [RFC PATCH v5 1/8] dma-mapping: add a device driver helper for iova contiguous Yoshihiro Shimoda
2019-06-05 11:11 ` [RFC PATCH v5 2/8] iommu/dma: move iommu_dma_unmap_sg() place Yoshihiro Shimoda
2019-06-05 11:11 ` [RFC PATCH v5 3/8] iommu: add a new capable IOMMU_CAP_MERGING Yoshihiro Shimoda
2019-06-05 12:21   ` Robin Murphy
2019-06-05 12:38     ` Christoph Hellwig [this message]
2019-06-06  6:28       ` Yoshihiro Shimoda
2019-06-06  7:00         ` Christoph Hellwig
2019-06-07  5:41           ` Yoshihiro Shimoda
2019-06-07  5:49             ` Christoph Hellwig
2019-06-07  6:01               ` Yoshihiro Shimoda
2019-06-06  5:53     ` Yoshihiro Shimoda
2019-06-05 16:17   ` Sergei Shtylyov
2019-06-05 11:11 ` [RFC PATCH v5 4/8] iommu/ipmmu-vmsa: add capable ops Yoshihiro Shimoda
2019-06-05 11:11 ` [RFC PATCH v5 5/8] mmc: tmio: No memory size limitation if runs on IOMMU Yoshihiro Shimoda
2019-06-05 11:11 ` [RFC PATCH v5 6/8] mmc: tmio: Add a definition for default max_segs Yoshihiro Shimoda
2019-06-05 11:11 ` [RFC PATCH v5 7/8] mmc: renesas_sdhi: sort headers Yoshihiro Shimoda
2019-06-05 11:11 ` [RFC PATCH v5 8/8] mmc: renesas_sdhi: use multiple segments if possible Yoshihiro Shimoda

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \

* 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).