[RFC 0/3] lib/fastmem: fast small-object allocator

[Mattias Rönnblom]

On 5/26/26 00:18, Stephen Hemminger wrote:
> On Mon, 25 May 2026 21:39:20 +0200
> Mattias Rönnblom <hofors at lysator.liu.se> wrote:
> 
>> On 5/25/26 16:30, Stephen Hemminger wrote:
>>> On Mon, 25 May 2026 12:36:39 +0200
>>> Mattias Rönnblom <hofors at lysator.liu.se> wrote:
>>>    
>>>> This RFC introduces fastmem, a general-purpose small-object allocator
>>>> for DPDK. It is intended to replace per-type mempools with a single
>>>> allocator that handles arbitrary sizes, grows on demand, and matches
>>>> mempool-level performance on the hot path.
>>>
>>> Makes sense, what a simple wrapper inline to allow full replacement
>>> testing/performance A/B comparison?
>>
>> Do you mean a mempool or a heap wrapper? Or both?
>>
>> I haven't looked into what options there are with mempools. A mempool
>> driver should be possible, but then I guess one might attempt a
>> whole-sale mempool-compatible API as well.
> 
> My thinking is a yet another allocator in DPDK is just another source
> of confusion and bugs. BUT if it can consolidate and fully replace
> one or more existing allocators then it would be great improvement.
> 
> Mempools are fast, but fixed and space inefficient.
> Rte_malloc is slow, but flexible.
> 
> Also, need to make whatever is added play well with static
> and dynamic checkers.

I'm not sure it's possible to replace mempools with a slab allocator 
like fastmem. They have different semantics, and I suspect that there 
are times when you prefer a mempool.

# Object Identity & Content Preservation

A mempool always returns one of the same pre-populated objects, with its 
contents untouched since last use. This enables pre-initialized fields, 
hardware-registered buffers, and constructors that run only once.

# Safe Use-After-Free

Returned objects remain valid, typed memory even after release. Stale 
references do not segfault or observe unrelated data, enabling RCU-style 
deferred reclamation.

# Bounded, Failure-Free Operation

A mempool operates with a fixed number of objects and performs no 
runtime memory allocation. This guarantees deterministic latency, 
natural backpressure, and eliminates `ENOMEM` failures after initialization.

# Known IOVA at Initialization Time

All object addresses, both virtual and physical, are fixed and 
enumerable from creation time. This enables pre-programming DMA 
descriptors and IOMMU registration.

# Memory Accounting

A mempool provides an exact, attributable memory footprint per pool, 
without sharing backing memory across unrelated users.

# Dense, Enumerable Object Set

Objects share a common base address and fixed stride, enabling efficient 
iteration and pointer compression.

Considering many apps use DPDK for I/O and other hardware abstraction 
only, and carry all other OS/kernel/platform type infrastructure 
themselves, replacing the mempools with something else will likely cause 
a lot of friction.

A fastmem-backed mempool backend (with limitations)? Sure.

Replacing rte_malloc seems easier, but I haven't looked into that in 
detail yet.