From: Christoph Hellwig <hch@lst.de>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Lu Baolu <baolu.lu@linux.intel.com>,
Christoph Hellwig <hch@lst.de>,
David Woodhouse <dwmw2@infradead.org>,
Joerg Roedel <joro@8bytes.org>,
ashok.raj@intel.com, jacob.jun.pan@intel.com, alan.cox@intel.com,
kevin.tian@intel.com, mika.westerberg@linux.intel.com,
pengfei.xu@intel.com,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 02/10] swiotlb: Factor out slot allocation and free
Date: Mon, 29 Apr 2019 13:44:01 +0200 [thread overview]
Message-ID: <20190429114401.GA30333@lst.de> (raw)
In-Reply-To: <90182d27-5764-7676-8ca6-b2773a40cfe1@arm.com>
On Mon, Apr 29, 2019 at 12:06:52PM +0100, Robin Murphy wrote:
>
> From the reply up-thread I guess you're trying to include an optimisation
> to only copy the head and tail of the buffer if it spans multiple pages,
> and directly map the ones in the middle, but AFAICS that's going to tie you
> to also using strict mode for TLB maintenance, which may not be a win
> overall depending on the balance between invalidation bandwidth vs. memcpy
> bandwidth. At least if we use standard SWIOTLB logic to always copy the
> whole thing, we should be able to release the bounce pages via the flush
> queue to allow 'safe' lazy unmaps.
Oh. The head and tail optimization is what I missed. Yes, for that
we'd need the offset.
> Either way I think it would be worth just implementing the straightforward
> version first, then coming back to consider optimisations later.
Agreed, let's start simple. Especially as large DMA mappings or
allocations should usually be properly aligned anyway, and if not we
should fix that for multiple reasons.
next prev parent reply other threads:[~2019-04-29 11:44 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-21 1:17 [PATCH v3 00/10] iommu: Bounce page for untrusted devices Lu Baolu
2019-04-21 1:17 ` [PATCH v3 01/10] iommu: Add helper to get minimal page size of domain Lu Baolu
2019-04-29 10:55 ` Robin Murphy
2019-04-30 0:40 ` Lu Baolu
2019-04-21 1:17 ` [PATCH v3 02/10] swiotlb: Factor out slot allocation and free Lu Baolu
2019-04-22 16:45 ` Christoph Hellwig
2019-04-23 1:58 ` Lu Baolu
2019-04-23 6:12 ` Christoph Hellwig
2019-04-23 7:32 ` Lu Baolu
2019-04-24 14:45 ` Christoph Hellwig
2019-04-25 2:07 ` Lu Baolu
2019-04-26 15:04 ` Christoph Hellwig
2019-04-29 5:10 ` Lu Baolu
2019-04-29 11:06 ` Robin Murphy
2019-04-29 11:44 ` Christoph Hellwig [this message]
2019-05-06 1:54 ` Lu Baolu
2019-05-13 7:05 ` Christoph Hellwig
2019-05-16 1:53 ` Lu Baolu
2019-04-30 2:02 ` Lu Baolu
2019-04-30 9:53 ` Robin Murphy
2019-05-02 1:47 ` Lu Baolu
2019-04-21 1:17 ` [PATCH v3 03/10] swiotlb: Limit tlb address range inside slot pool Lu Baolu
2019-04-21 1:17 ` [PATCH v3 04/10] swiotlb: Extend swiotlb to support page bounce Lu Baolu
2019-04-21 1:17 ` [PATCH v3 05/10] iommu: Add bounce page APIs Lu Baolu
2019-04-21 1:17 ` [PATCH v3 06/10] iommu/vt-d: Add trace events for domain map/unmap Lu Baolu
2019-04-21 1:17 ` [PATCH v3 07/10] iommu/vt-d: Keep swiotlb on if bounce page is necessary Lu Baolu
2019-04-22 16:47 ` Christoph Hellwig
2019-04-23 2:00 ` Lu Baolu
2019-04-21 1:17 ` [PATCH v3 08/10] iommu/vt-d: Check whether device requires bounce buffer Lu Baolu
2019-04-22 16:47 ` Christoph Hellwig
2019-04-23 2:03 ` Lu Baolu
2019-04-23 6:08 ` Christoph Hellwig
2019-04-23 7:35 ` Lu Baolu
2019-04-24 18:27 ` Konrad Rzeszutek Wilk
2019-04-21 1:17 ` [PATCH v3 09/10] iommu/vt-d: Add dma sync ops for untrusted devices Lu Baolu
2019-04-21 1:17 ` [PATCH v3 10/10] iommu/vt-d: Use bounce buffer " Lu Baolu
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=20190429114401.GA30333@lst.de \
--to=hch@lst.de \
--cc=alan.cox@intel.com \
--cc=ashok.raj@intel.com \
--cc=baolu.lu@linux.intel.com \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=jacob.jun.pan@intel.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mika.westerberg@linux.intel.com \
--cc=pengfei.xu@intel.com \
--cc=robin.murphy@arm.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).