Re: [PATCH v2 2/5] swiotlb/mm: Implement SWIOTLB nocopy page allocator

On 24.08.26 18:30, Luigi Rizzo wrote:

On Mon, Aug 24, 2026 at 6:06 PM Robin Murphy [off-list ref] wrote:

quoted

On 2026-08-24 4:29 pm, Luigi Rizzo wrote:

quoted

Introduce swiotlb_alloc_pages() and swiotlb_free_pages() to allocate
and release compound pages directly from the default SWIOTLB pool.

Huh? The sole intended purpose of SWIOTLB is for bounce-buffering data
which already exists in some other memory that is unsuitable for DMA for
whatever reason. If you want to allocate directly from some kind of
pre-shared DMA page pool to avoid bounce-buffering, set up some kind of
pre-shared DMA page pool and allocate from that in a manner which can
avoid bouncing entirely (see DMA_ATTR_CC_SHARED). The idea of getting as
far as calling swiotlb_bounce() to then have a special case saying "haha
not really" seems entirely absurd. Don't hack stuff into the SWIOTLB
code which has no business being there.

Ah I see DMA_ATTR_CC_SHARED did not exist when I implemented the
swiotlb allocator. Cool, one less piece, it should be possible to replace
this chunk witth the DMA_ATTR_CC_SHARED.

I agree with Robin's point (if I understood it correctly):
Why should it at all pass through the SWIOTLB? Why can't it be a standalone
DMA pool?

The other pieces are still relevant though ?

- use these dma-able pages for page pool allocations (small)
- [PATCH v2 3/5] net/swiotlb: Track bounce device per socket
  or one would have to unconditionally allocate from that pool,
  even for e.g. local sockets
- divert socket allocations for eligible sockets to a DMA-able pool

Thanks,
Dragos