Re: [RFC: DMA_PMD 00/22] DMA_PMD: PMD_SIZE-backed IO buffer pools

On Wed, Oct 14, 2026 at 12:48 PM David Hildenbrand (Arm)
[off-list ref] wrote:

On 10/13/26 12:42, Robin Murphy wrote:

quoted

On 12/10/2026 8:43 pm, David Hildenbrand (Arm) wrote:

quoted

On 10/12/26 16:45, Luigi Rizzo wrote:

quoted

On Mon, Oct 12, 2026 at 3:51 PM David Hildenbrand (Arm)
[off-list ref] wrote:

I had to call it something... an earlier prototype used the name IOMMU_2M,
but I didn't want to suggest that the design was limited to 2M (it is not).

Aside from the name, the _current_ prototype restricts to 2M allocations,
exactly because too large units are expensive and wasteful.

In the code, decoupling the allocation size from the PMD size is trivial.

Yeah, we should do that.

We should probably just find a way to describe that this is a POOL that focuses
on physical contiguity in some configured granularity.

And since it's intended for DMA we could call it dma_pool and oh look it already
exists...

Heh, I did have "DMA_POOL" in mind when writing my reply.

which confirms that naming is one of the hardest problems in CS...
Let's try to figure out a good name before renaming everything.

quoted

Sure the current implementation is capped at PAGE_SIZE for allocation (and thus
mapping too), but I don't see why that couldn't just be made more flexible.

That intuitively sounds like the right direction.

Point taken, I will decouple the allocaiton size from PMD_SIZE this in
the next iteration.

I have also followed up on most of Pranjal's feedback (stricter error checking,
compact IOVA ranges, opt-in per destination on the tx path...) .

I am also looking at reducing some inefficiencies (e.g. pagepool already caches,
and allocations of new pages are relatively rare, so there is not much
of a point
of having a dma_pmd_pool per queue; and on the tx side, something similar to the
percpu page cache to reduce locking costs when a page is allocated on one CPU
and freed on a different one)

cheers
luigi