It's not a black and white free list vs malloc API situation.

It is in the sense that if finding a buffer that's the right length was just as slow as malloc (and free) then you would just use malloc.

Not only that but malloc is shared with the entire program and can do a lot of locking. On top of that there is the memory locality of using the same heap as the rest of the program.

If you just make your own heap there is a big difference between using the system allocator over and over and reusing local memory buffers for a specific thread and purpose.

What you're describing here the same thing, avoiding the global heap allocator.

Well, allocating and freeing according to need is reusing

That's a twisted definition. It seems like you're playing around with terms, but allocating memory from a heap allocator is obviously what people are talking about with "dynamic memory allocation". Reusing memory that has already been grabbed from an allocator is not reallocating memory. If you have a buffer and it works you don't need to do anything to reuse it.

Modern TCP perf is not bottlenecked by that. There's pools of recycled buffers that grow and shrink according to load etc.

If anything is allocating memory from the heap in a hot loop it will be a bottleneck.

Reusing buffers is not allocating memory dynamically.

Needing memory doesn't have to mean allocating memory over and over. Memory allocation is expensive. If someone is doing that reusing memory is going to be by far the best optimization.

You need some memory but that doesn't mean you would constantly allocate memory. There is a big difference between a few allocations and allocating in a hot loop.

Are there TCP/IP stacks out there in common use that are allocating memory all the time?