[lwip-devel] [bug #3031] Implement a new fully pool-based pbuf implementation.

[Jonathan Larmour]

Follow-up Comment #3, bug #3031 (project lwip):

By having multiple separate pools, you increase overall RAM memory use -
which is far more of an issue than code footprint for most embedded systems.
It's inevitable you will sometimes run out of memory in one pool while still
having memory in another, which is wasteful. And pools of fixed chunks which
don't fit the allocations will intrinsically have waste. Statistical analysis
may reduce some but not all of the overhead, and only really helps "average"
operation.

If you want to be memory efficient, you should only use pools of fixed size
memory chunks for fixed size allocations. With fixed size allocations that is
when an implementation like the current memp one becomes efficient, rather
than wasteful as Atte states: users can fine-tune precisely the resources to
match the number of TCP connections (pcbs), in-flight TCP segments, etc. they
intend to support. They are tuning lwIP so that it will meet their
requirements, rather than statistically assume that sometimes it will,
sometimes it may not, because you gave it a fairly arbitrarily chosen lump of
memory to play with. Otherwise it can mean that "low priority" allocations can
use up memory for high priority ones - dropping a packet can be recovered from
far more easily than no longer being able to create new outbound connections.
The point is, the user chooses how to divide the resources according to the
application requirements.

No, it may not be as fast, but lwIP's primary goal is low memory use. Speed
is secondary.

If people want this type of solution then I think it must be a configurable
option. With what Leon describes, achieving that wouldn't be so hard - he's
only referring to pbuf allocations, so that's all fairly self-contained.
Trying to adopt fixed size pools for all pbufs permanently, or for variable
sized quantities more generally (although it is true that there aren't many
non-pbuf variable sized allocations around), or using wrongly sized pools for
fixed size quantities, would be bad.  

I'm using lwIP on systems with 32K RAM and I believe should get into 16K for
some people with simpler applications. I strongly suspect Atte and Simon have
significantly more memory. I think it would be a step in the wrong direction
to increase memory overheads for everyone.


    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?3031>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/