[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [RFC 1/1] swiotlb: Reduce calls to swiotlb_find_pool()
- To: "hch@xxxxxx" <hch@xxxxxx>
- From: Michael Kelley <mhklinux@xxxxxxxxxxx>
- Date: Sun, 30 Jun 2024 14:02:52 +0000
- Accept-language: en-US
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8lTk4hRxrZhQ/fhyVY54JOkDpKaShrolCHbrWuRPTV0=; b=PGnnSPbu9rczOnneGT1dY6Xz+iTjim8eTRfnvcpb4BLExuQS99cX0EpnjYzUzGg09iK3ESGptUVpfELAheMMYtaytLiWueKmXLT2bVwGPEbH9Nir3AgPWGnz7OFFojBShLkZwmKs3o7vviDAZLjnqcGEV2I6BlQCDfo8Z5sYPgNN8l7dGLCYYLq6h4IGNsE2+TDNzq4UKvZw25wyyxOGvKxL3DN0M6KZrH/P61semK6fKIy+QbWCfjoMLInsAahdQ2MYtCdQ+W0RDaufkjfKnK7l1Vht37JCpEIZcZZ2B5aHQ0AtVEt2POQIQxzpwJTcVfcHfPWClBAa49zWI04lJw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GjolRelm4fBf2AJ1viX42J42cGZwBz4dJ7RKBo1ufunzq87nLc+qoqDRw9uQnkwPp42rKimrEf8lvBb+JAdMTXRC5Rjm1lGFkfC2DrfXtbASA9quh8nAzogEbtDkRREJlf6Xfyt79mNms0KLE9kalqrDVvhCWeZLdzDJhCbB9gjIzay+zM5motSpSip7I3sM7mbWV72AxIO3wVSMSUtK63v0L8NnQsL/IDZc7W3XXMc5kaA7UYoVvqXwGQTwubk3ewnL8fBfj+z9LUdzMXAaSQaXVgtg0UR/B/QbMkLHUbR6VOyQuhnN4A4rlYVDHv9Yub6wZI1PNMnVOYT64wkelQ==
- Cc: Petr Tesařík <petr@xxxxxxxxxxx>, "robin.murphy@xxxxxxx" <robin.murphy@xxxxxxx>, "joro@xxxxxxxxxx" <joro@xxxxxxxxxx>, "will@xxxxxxxxxx" <will@xxxxxxxxxx>, "jgross@xxxxxxxx" <jgross@xxxxxxxx>, "sstabellini@xxxxxxxxxx" <sstabellini@xxxxxxxxxx>, "oleksandr_tyshchenko@xxxxxxxx" <oleksandr_tyshchenko@xxxxxxxx>, "m.szyprowski@xxxxxxxxxxx" <m.szyprowski@xxxxxxxxxxx>, "iommu@xxxxxxxxxxxxxxx" <iommu@xxxxxxxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Sun, 30 Jun 2024 14:03:25 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHauIjoJBWSrCyO6UWzcncSceBiMLHa1Z9wgABomICAAA3OAIAAhiSggAAJLYCAAAn5IIAA6tuAgAAdhQCAAhqHMIAA6wAAgACDZAA=
- Thread-topic: [RFC 1/1] swiotlb: Reduce calls to swiotlb_find_pool()
From: hch@xxxxxx <hch@xxxxxx> Sent: Saturday, June 29, 2024 10:56 PM
>
> On Sat, Jun 29, 2024 at 03:55:58PM +0000, Michael Kelley wrote:
> > Unless there is further discussion on this point, I'll just keep the
> > original
> > "is_swiotlb_buffer()" in v2.
>
> That is the wrong name for something that returns the pool as pointed
> out before.
OK. Since any new name could cause confusion with the existing
swiotlb_find_pool(), here's my proposal:
1) Rename is_swiotlb_buffer() to swiotlb_find_pool(), since it
now returns a pool. A NULL return value indicates that the
paddr is not an swiotlb buffer.
2) Similarly, rename is_xen_swiotlb_buffer() to
xen_swiotlb_find_pool()
3) The existing swiotlb_find_pool() has the same function signature,
but it is used only where the paddr is known to be an swiotlb buffer
and hence always succeeds. Rename it to __swiotlb_find_pool() as
the "internal" version of swiotlb_find_pool().
4) Do you still want is_swiotlb_buffer() as a trivial wrapper around
the new swiotlb_find_pool(), for use solely in dma_direct_need_sync()
where only a Boolean is needed and not the pool?
Thanks,
Michael
|