From: Robin Murphy <robin.murphy@arm.com>
To: John Garry <john.garry@huawei.com>,
joro@8bytes.org, will@kernel.org, mst@redhat.com,
jasowang@redhat.com
Cc: xieyongji@bytedance.com, linux-kernel@vger.kernel.org,
iommu@lists.linux-foundation.org,
virtualization@lists.linux-foundation.org, linuxarm@huawei.com,
thunder.leizhen@huawei.com, baolu.lu@linux.intel.com
Subject: Re: [PATCH 4/5] iommu: Separate IOVA rcache memories from iova_domain structure
Date: Mon, 20 Dec 2021 13:57:17 +0000 [thread overview]
Message-ID: <85c60ef4-e1af-c947-a2ed-b63c4fef36c3@arm.com> (raw)
In-Reply-To: <2c58036f-d9aa-61f9-ae4b-f6938a135de5@huawei.com>
Hi John,
On 2021-12-20 08:49, John Garry wrote:
> On 24/09/2021 11:01, John Garry wrote:
>> Only dma-iommu.c and vdpa actually use the "fast" mode of IOVA alloc and
>> free. As such, it's wasteful that all other IOVA domains hold the rcache
>> memories.
>>
>> In addition, the current IOVA domain init implementation is poor
>> (init_iova_domain()), in that errors are ignored and not passed to the
>> caller. The only errors can come from the IOVA rcache init, and fixing up
>> all the IOVA domain init callsites to handle the errors would take some
>> work.
>>
>> Separate the IOVA rache out of the IOVA domain, and create a new IOVA
>> domain structure, iova_caching_domain.
>>
>> Signed-off-by: John Garry <john.garry@huawei.com>
>
> Hi Robin,
>
> Do you have any thoughts on this patch? The decision is whether we stick
> with a single iova domain structure or support this super structure for
> iova domains which support the rcache. I did not try the former - it
> would be do-able but I am not sure on how it would look.
TBH I feel inclined to take the simpler approach of just splitting the
rcache array to a separate allocation, making init_iova_rcaches() public
(with a proper return value), and tweaking put_iova_domain() to make
rcache cleanup conditional. A residual overhead of 3 extra pointers in
iova_domain doesn't seem like *too* much for non-DMA-API users to bear.
Unless you want to try generalising the rcache mechanism completely away
from IOVA API specifics, it doesn't seem like there's really enough to
justify the bother of having its own distinct abstraction layer.
Cheers,
Robin.
next prev parent reply other threads:[~2021-12-20 13:57 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-24 10:01 [PATCH 0/5] iommu: Some IOVA code reorganisation John Garry
2021-09-24 10:01 ` [PATCH 1/5] iova: Move fast alloc size roundup into alloc_iova_fast() John Garry
2021-10-04 11:31 ` Will Deacon
2021-10-08 16:20 ` John Garry
2021-10-09 3:12 ` Yongji Xie
2021-10-11 2:06 ` Jason Wang
2021-10-27 9:25 ` John Garry
2021-10-18 15:42 ` Michael S. Tsirkin
2021-09-24 10:01 ` [PATCH 2/5] iommu: Separate flush queue memories from IOVA domain structure John Garry
2021-09-24 10:01 ` [PATCH 3/5] iommu: Move IOVA flush queue code to dma-iommu John Garry
2021-09-24 10:01 ` [PATCH 4/5] iommu: Separate IOVA rcache memories from iova_domain structure John Garry
2021-12-20 8:49 ` John Garry
2021-12-20 13:57 ` Robin Murphy [this message]
2021-12-22 11:53 ` John Garry
2021-09-24 10:01 ` [PATCH 5/5] iommu/iova: Avoid double-negatives in magazine helpers John Garry
2021-10-04 11:38 ` Will Deacon
2021-10-04 13:33 ` John Garry
2021-10-04 11:44 ` [PATCH 0/5] iommu: Some IOVA code reorganisation Will Deacon
2021-10-04 13:56 ` John Garry
2021-10-04 14:48 ` Robin Murphy
2021-11-16 14:21 ` John Garry
2021-11-16 14:25 ` Robin Murphy
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=85c60ef4-e1af-c947-a2ed-b63c4fef36c3@arm.com \
--to=robin.murphy@arm.com \
--cc=baolu.lu@linux.intel.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jasowang@redhat.com \
--cc=john.garry@huawei.com \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=mst@redhat.com \
--cc=thunder.leizhen@huawei.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=will@kernel.org \
--cc=xieyongji@bytedance.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