From: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
To: Mostafa Saleh <smostafa@google.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>,
Robin Murphy <robin.murphy@arm.com>,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
Jagadeesh Pagadala <jpagadal@qti.qualcomm.com>
Subject: Re: [PATCH] swiotlb: introduce Kconfig option for compile-time default pool size
Date: Wed, 17 Jun 2026 21:43:21 +0530 [thread overview]
Message-ID: <6cbf7d5b-cf7c-4b31-b60e-06e508c633ca@oss.qualcomm.com> (raw)
In-Reply-To: <CAFgf54r0oXgaFMQeBOV+jm70XoMUKFAOkRhNLM2FrFa_JhmwKA@mail.gmail.com>
On 6/17/2026 2:17 PM, Mostafa Saleh wrote:
> On Tue, Jun 16, 2026 at 10:36 PM <bibek.patro@oss.qualcomm.com> wrote:
>>
>> From: Jagadeesh Pagadala <jpagadal@qti.qualcomm.com>
>>
>> The SWIOTLB bounce buffer pool size is hardcoded at 64 MB via
>> IO_TLB_DEFAULT_SIZE with no compile-time knob to adjust it. On
>> memory-constrained embedded or mobile platforms equipped with a
>> hardware IOMMU (e.g., ARM SMMU) covering most DMA-capable devices,
>> reserving 64 MB at boot is unnecessarily wasteful — the SWIOTLB is
>> only exercised for devices that bypass the IOMMU or have restricted
>> DMA address ranges.
>>
>> Introduce CONFIG_SWIOTLB_DEFAULT_SIZE_MB, an integer Kconfig option
>> (range 1–64 MB, default 64) that allows platforms to set a smaller
>> compile-time default. IO_TLB_DEFAULT_SIZE is updated to derive from
>> this value when CONFIG_SWIOTLB is enabled, preserving the existing
>> 64 MB default when the option is not configured.
>>
>> The runtime "swiotlb=<nslabs>" kernel parameter override remains
>> fully supported and takes precedence over the compile-time default.
>>
>
> Just curious, why is not "swiotlb=" enough in your case?
>
We are looking for an approach where we can set a default value of
IO_TLB_DEFAULT_SIZE to maintain and sustain it for a
specific platform or a kernel configuration.
So introducing a Kconfig tunable seemed to be a maintainable approach
compared to "swiotlb=" runtime variable.
(since defconfig is the right mechanism for platform specific
compile-time defaults)
Further in case of any bootloader constraints - to make default runtime
parameter, it might require firmware changes on production devices as
well. (since in embedded/mobile platforms the kernel command line is
typically managed by the bootloader)
Thanks & regards,
Bibek
> Thanks,
> Mostafa
>
>> Signed-off-by: Jagadeesh Pagadala <jpagadal@qti.qualcomm.com>
>> Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>> ---
>> The SWIOTLB bounce buffer pool size is hardcoded at 64 MB. On
>> memory-constrained platforms with a hardware IOMMU (e.g., ARM SMMU),
>> this reservation is wasteful as SWIOTLB is only needed for devices
>> that bypass the IOMMU or have restricted DMA address ranges.
>>
>> Introduce CONFIG_SWIOTLB_DEFAULT_SIZE_MB (range 1–64 MB, default 64)
>> to allow a smaller compile-time default. The runtime "swiotlb="
>> parameter override remains supported and takes precedence.
>>
>> Before (default 64 MB):
>> [ 0.000000] software IO TLB: area num 8.
>> [ 0.000000] software IO TLB: mapped [mem 0x00000000fbfff000-0x00000000fffff000] (64MB)
>>
>> After (CONFIG_SWIOTLB_DEFAULT_SIZE_MB=2):
>> [ 0.000000] software IO TLB: area num 8.
>> [ 0.000000] software IO TLB: SWIOTLB bounce buffer size roundup to 2MB
>> [ 0.000000] software IO TLB: mapped [mem 0x00000000ffdff000-0x00000000fffff000] (2MB)
>> ---
>> include/linux/swiotlb.h | 8 ++++++--
>> kernel/dma/Kconfig | 22 ++++++++++++++++++++++
>> 2 files changed, 28 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
>> index 3dae0f592063..1665a9ce8f94 100644
>> --- a/include/linux/swiotlb.h
>> +++ b/include/linux/swiotlb.h
>> @@ -32,8 +32,12 @@ struct scatterlist;
>> #define IO_TLB_SHIFT 11
>> #define IO_TLB_SIZE (1 << IO_TLB_SHIFT)
>>
>> -/* default to 64MB */
>> -#define IO_TLB_DEFAULT_SIZE (64UL<<20)
>> +/* compile-time default; overridable via CONFIG_SWIOTLB_DEFAULT_SIZE_MB */
>> +#ifdef CONFIG_SWIOTLB
>> +#define IO_TLB_DEFAULT_SIZE ((unsigned long)CONFIG_SWIOTLB_DEFAULT_SIZE_MB << 20)
>> +#else
>> +#define IO_TLB_DEFAULT_SIZE (64UL << 20)
>> +#endif
>>
>> unsigned long swiotlb_size_or_default(void);
>> void __init swiotlb_init_remap(bool addressing_limit, unsigned int flags,
>> diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
>> index 0a4ba21a57a7..3830a63ae032 100644
>> --- a/kernel/dma/Kconfig
>> +++ b/kernel/dma/Kconfig
>> @@ -86,6 +86,28 @@ config SWIOTLB
>> bool
>> select NEED_DMA_MAP_STATE
>>
>> +config SWIOTLB_DEFAULT_SIZE_MB
>> + int "Default SWIOTLB bounce buffer size in MB"
>> + depends on SWIOTLB
>> + range 1 64
>> + default 64
>> + help
>> + Sets the default size of the software IO TLB (SWIOTLB) bounce buffer
>> + pool allocated at boot time. The default is 64 MB.
>> +
>> + On memory-constrained embedded or mobile platforms (e.g., those with
>> + a hardware IOMMU such as ARM SMMU covering most DMA-capable devices),
>> + a smaller value such as 4 or 8 MB may be sufficient. The SWIOTLB is
>> + then only needed for devices that bypass the IOMMU or have restricted
>> + DMA address ranges.
>> +
>> + The minimum allowed value is 1 MB. This compile-time default can be
>> + overridden at runtime using the "swiotlb=<nslabs>" kernel command line
>> + parameter. Refer to Documentation/admin-guide/kernel-parameters.txt
>> + for details.
>> +
>> + If unsure, leave at the default value of 64.
>> +
>> config SWIOTLB_DYNAMIC
>> bool "Dynamic allocation of DMA bounce buffers"
>> default n
>>
>> ---
>> base-commit: 4fa3f5fabb30bf00d7475d5a33459ea83d639bf9
>> change-id: 20260617-swiotlb-c215ce0b23f7
>>
>> Best regards,
>> --
>> Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>>
>>
next prev parent reply other threads:[~2026-06-17 16:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-16 21:36 bibek.patro
2026-06-17 8:47 ` Mostafa Saleh
2026-06-17 16:13 ` Bibek Kumar Patro [this message]
2026-06-18 16:04 ` Michael Kelley
2026-06-22 14:45 ` Bibek Kumar Patro
2026-07-02 13:44 ` Bibek Kumar Patro
2026-07-02 15:48 ` Michael Kelley
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=6cbf7d5b-cf7c-4b31-b60e-06e508c633ca@oss.qualcomm.com \
--to=bibek.patro@oss.qualcomm.com \
--cc=iommu@lists.linux.dev \
--cc=jpagadal@qti.qualcomm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=robin.murphy@arm.com \
--cc=smostafa@google.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