Re: [lwip-devel] mem(p) allocator change request

[lukem . lwip]

On Tue, 30 Mar 2004 address@hidden wrote:
> > user could then register one or more of these structs to be used at
> > different points in lwIP --- thus allowing an arbitrary number of
> > allocators, which can be as specialised as you like, or alternately you
> > can pass a single general purpose allocator to everything --- it is, as
> > it should be, the developers choice.
>
> Think a few defines should be enough. Also think everyone wants to
> limit the number of different alloactors in their system.

Please consider the solution I proposed carefully, as I think there is
merit in providing more flexibility than merely #define-ing all memp_
functions to one allocator, and all mem_ functions to another allocator.

There are reasons you might want to have different allocators for
different buffer types. For example, a PCB should never be sent over
ethernet, while a packet header will be. By allowing different allocators
for different types, we allow the user to do things like allocate packet
headers from DMA pinned memory for example, while other types can use
regular memory.

On one operating system I work on it would be nice to allocate some
buffers from a shared memory space and others that are internal to lwIP in
a different, private bit of memory.

Another reason for doing this might be that you knwo something about the
lifespan of particular types. Perhaps you would like to allocate all
short-lived objects using one allocator, and all long-lived objects from
another.

There are a lot of reasons why providing a real API for this would be a
good idea, and the one I proposed earlier would provide this flexibility
and more, without unnecessarilty burdening systems which do not want or
need this functionality.

The minimum memory overhead would simply be one pointer for each of the
pool types, plus one or two of the descriptor structs (two if you want a
general purpose plus a pool allocator as in the current system). This
should be small enough to keep the embedded people happy.

The extra CPU overhead is just the extra indirection(s) when doing the
function call, which are probably so small in the scheme of things that
they are not worth considering.

--
Luke