On 5/26/26 00:18, Stephen Hemminger wrote:
On Mon, 25 May 2026 21:39:20 +0200
Mattias Rönnblom <[email protected]> wrote:
On 5/25/26 16:30, Stephen Hemminger wrote:
On Mon, 25 May 2026 12:36:39 +0200
Mattias Rönnblom <[email protected]> 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.
