10:44 <atorgue> Hi, short question about SWIOTLB. It seems that the maximum contiguous buffer allocable is 256 kB defined by the “#define IO_TLB_SEGSIZE128” in include/linux/swiotlb.h. Comment in this file explains that this value could be tuned. I saw some initiatives (patches) to do it either through command line or Kconfig but never merged. Somebody knows

10:44 <atorgue> why? Is it because we don’t want to tune it ?

11:47 <robmur01> atorgue: was that the discussion which ended up pivoting into the introduction of dma_max_mapping_size()? The consensus these days is that larger bounces are generally indicative of the caller doing something wrong (or at least suboptimal), so it's better to look at the callers and aim to fix them

11:49 <robmur01> I believe the segment size has a fairly big impact on SWIOTLB performance, which people increasingly care about these days

11:50 <robmur01> (since it's being used more generally for confidential compute scenarios, rather than just a fallback for the occasional DMA addressing limitation)

12:00 <atorgue> robmur01: Thanks Robin. When you say that the caller must to be fix, are you talking about the way to allocate buffers (either through reserved memory well placed in the first 2GB of memory or using GFP_DMA32) or do you have something else in mind ?

12:03 <atorgue> *the first 2GB of DDR memory (0x8000 0000 to 0xffff ffff)

12:21 <robmur01> depends on the scenario - in cases like the NVMe one it's a simple matter of just tweaking things to ensure the mapping is split into reasonably sized segments

12:22 <robmur01> others like vb2_dma_contig are where it only hits SWIOTLB at all because the code is doing fundamentally the wrong thing (e.g. that one wants reworking to use a proper DMA allocator)

12:30 <atorgue> Allocate a buffer of 512KB (kzalloc + GFP_KERNEL)  and use a dma_map_single API is wrong and should be split into to transfer of 256KB each ?

12:32 <atorgue> (I did some trials with dmatest)

12:53 <robmur01> well, it's not "wrong" if you're happy to handle failure, but if you want to know if it has any chance of ever succeeding then check dma_max_mapping_size() first and work based on that

12:57 <atorgue> Ok, so instead of chenge swiotlb code, it is better to split transfers according to dma_max_mapping_size() return value

12:57 <robmur01> however for allocating large dedicated DMA buffers (other than the coherent APIs) you really want to be going to dma_alloc_pages()

15:12 <atorgue> robmur01: (sorry for my late answer). Yes and it is case (using dma_alloc_pages without coherent API) the driver must verify the transfer capability using dma_max_mapping_size

15:15 <atorgue> If yes. It is maybe something to add into dmatest driver