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

[Atte Kojo]

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

> I strongly suspect Atte and Simon have significantly more memory.

I have 72Kish (depending on how you count, my byte is 24 bits) for the whole
system and the application pushes a lot of data through the stack (maximum 12
channels of data @ 10 kHz), although using UDP. TCP is used for control
connections.

Jonathan, I'm sorry but I really didn't understand your argument against my
suggestion about multiple memory pools. As of now lwIP has three memory
managers (mem_, memp_, and pbuf) of which memp has *11* memory pools, one for
each dynamic structure type. It is a difficult system for a beginner to
understand, let alone tune. At least I was confused for quite some time ;-).

I personallty don't see a problem in using a fixed-size pool allocator in
low-memory systems; the pool sizes just have to be tuned appropriately. There
are several possible methods for this. If an application sends and receives a
lot of small packets (text-based communication, for example) with an
occasional large packet, the pools can be configured to be small and pbuf
chaining takes care of the large packets. To complement this TCP's MSS option
can be used to keep TCP packets reasonably small.

Using any fully-functional TCP/IP stack on a system with 16K of RAM is going
to be a tight fit, but I don't see any reason why it couldn't be done using
fixed-size pools with proper tuning. I'm also guessing that systems with 16K
of RAM don't have very large ROMs either so the code space savings are also
going to matter in such systems.

BTW, I don't see any good reason the use a buddy allocator over a decent
malloc implementation in a small-memory system. As far as I understand with
small block sizes a buddy allocator has the same fragmentation problems as a
dynamic allocator. And is probably just as complicated to implement, too.

    _______________________________________________________

Reply to this item at:

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

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