linux-renesas-soc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: Christoph Hellwig <hch@lst.de>,
	Robin Murphy <robin.murphy@arm.com>,
	"ulf.hansson@linaro.org" <ulf.hansson@linaro.org>,
	"wsa+renesas@sang-engineering.com"
	<wsa+renesas@sang-engineering.com>,
	"m.szyprowski@samsung.com" <m.szyprowski@samsung.com>,
	"joro@8bytes.org" <joro@8bytes.org>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"linux-renesas-soc@vger.kernel.org" 
	<linux-renesas-soc@vger.kernel.org>
Subject: Re: [RFC PATCH v5 3/8] iommu: add a new capable IOMMU_CAP_MERGING
Date: Thu, 6 Jun 2019 09:00:59 +0200	[thread overview]
Message-ID: <20190606070059.GI27033@lst.de> (raw)
In-Reply-To: <OSAPR01MB3089448A3D44BE61B127AA73D8170@OSAPR01MB3089.jpnprd01.prod.outlook.com>

On Thu, Jun 06, 2019 at 06:28:47AM +0000, Yoshihiro Shimoda wrote:
> > 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.
> 
> I'm afraid but I don't understand why 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.

Assume a device (which I think is your case) that only supports a single
segment in hardware.  In that case we set max_segments to 1 if no
IOMMU is present.  But if we have a merge capable IOMMU we can set
max_segments to unlimited (or some software limit for scatterlist
allocation), as long as we set a virt_boundary matching what the IOMMU
expects, and max_sectors_kb isn't larger than the max IOMMU mapping
size.  Now we could probably just open code this in the driver, but
I'd feel much happier having a block layer like this:

bool blk_can_use_iommu_merging(struct request_queue *q, struct device *dev)
{
	if (!IOMMU_CAN_MERGE_SEGMENTS(dev))
		return false;

	blk_queue_virt_boundary(q, IOMMU_PAGE_SIZE(dev));
	blk_queue_max_segment_size(q, IOMMU_MAX_SEGMENT_SIZE(dev));
	return true;
}

and the driver then does:

	if (blk_can_use_iommu_merging(q, dev)) {
		blk_queue_max_segments(q, MAX_SW_SEGMENTS);
		// initialize sg mempool, etc..
	}


Where the SCREAMING pseudo code calls are something we need to find a
good API for.

And thinking about it the backend doesn't need to be an iommu, swiotlb
could handle this as well, which might be interesting for devices
that need to boune buffer anyway.  IIRC mmc actually has some code
to copy multiple segments into a bounce buffer somewhere.

> The block layer already has a limit "max_segment_size" for each device so that
> regardless it can/cannot merge the segments, we can use the limit.
> Is my understanding incorrect?

Yes.

  reply	other threads:[~2019-06-06  7:01 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
2019-06-06  6:28       ` Yoshihiro Shimoda
2019-06-06  7:00         ` Christoph Hellwig [this message]
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:
  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=20190606070059.GI27033@lst.de \
    --to=hch@lst.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=robin.murphy@arm.com \
    --cc=ulf.hansson@linaro.org \
    --cc=wsa+renesas@sang-engineering.com \
    --cc=yoshihiro.shimoda.uh@renesas.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).