[lwip-users] RFC: Let's design a new pbuf API + pseudocode

[Leon Woestenberg]

Hello all,

thanks for the discussion and feedback all! Let's use the momentum to
improve on lwIP :-)

> The only drawback with fragmenting into many pools like this (it will make
> it easier in terms of locking that's for sure) is the situation where one
> pool runs out of memory but another has loads free.  It's a change in
>
Currently we have "random" memory holes in the memory allocator for
the PBUF_RAM types.

Besides, why not allow pbuf_alloc_chain() where the user gets a chain
instead of a single pbuf? This would work in every case which is "pbuf
chain aware". Note that the netif-to-application direction of the stack
should be already pbuf-chain-aware, as PBUF_POOLs are mostly
chained.

Proposal:

/**
 * Allocate a chain of pbufs, where the header is fully in the first pbuf.
 *
 * @param header_len
 * @param payload_len
 *
 * @return chain of pbufs, first having length at least header_len.
 */
struct pbuf *pbuf_alloc_chain(header_len, payload_len)

/**
 * Allocate a pbuf of given length.
 *
 * @param length
 *
 * @return pbuf of given length
 */
struct pbuf *pbuf_alloc(length)


> philosophy away from the "lwIP is a really low memory usage stack".  This
> doesn't bother me particularly, but it might others.
>
Simplifying the architecture will remove a lot of ROM code as well. With the
approach as set out above, I do not expect a substantial increase in RAM
cost.

The current implementation has a reasonable amount of mem/memp/pbuf
overhead, besides the usual C library stuff that is already there in most
(embedded) applications.

Regards, Leon.