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

[christiaan . simons]

address@hidden wrote on 30-03-2004
01:14:17:

> On Mon, 29 Mar 2004 address@hidden wrote:

> The thing is, no-one has actually shown that memory fragmentation is
> actually an issue for the allocation patterns we have in lwIP.

I think this is because all dynamic bits are stored using memp instead of
mem...

> Basically, we allocate lots of small, similar sized objects, which mostly
have short
> lifespans.

> First, this is unlikely to happen in lwIP, and second,
> the current solution solves the problem by wasting even more space ---
> that is, unless you know exactly how many of each pool type you will need
> in advance --- which I doubt (m)any people do.

Hmm, I don't think allocating a MIB object for a few weeks is
as short as storing a TCP segment for a few microsec...
Second point: many embedded engineers want to know the
memory requirements in advance.


> Now we can all hand-wave about fragmentation, but until someone
> demonstrates that it is an issue in practice, and that more memory is
lost

Isn't an issue. This is a form of early optimalisation you might
want to avoid... Though I agree; for really huge amounts of connections
the lwip stack isn't very memory and cycle effiecient.

Maybe you want to use another stack which is closer to your requirements...


> The conclusions reached in the earlier discussion is that we can address
> the fact that different users of lwIP have different needs by providing a
> decent abstraction for memory allocation. This should keep everybody
> happy, because we can each have an allocator which suits our own set of
> tradeoffs.

Okay, I'll make it selectable!

> 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.

> --
> Luke
>



The information contained in this communication is confidential and is
intended solely for the use of the individual or entity to whom it is
addressed. Axon Digital Design Group is neither liable for the proper nor
for the complete transmission of the information contained in this
communication nor for any delay in its receipt. Axon Digital Design Group
does not guarantee that the integrity of this communication has been
maintained nor that the communication is free of viruses, interceptions or
interference. If you are not the intended recipient of this communication,
you are hereby notified that reading, disseminating, distributing or
copying this message is strictly prohibited. In that case please return the
communication to the sender and delete and destroy all copies. In carrying
out its engagements, Axon Digital Design Group applies general terms and
conditions, which contain a clause that limits its liability. A copy of
these terms and conditions is available on request free of charge.