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

[Jonathan Larmour]

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

Yes, I was slightly more concerned about Atte's suggestion of making
everything come from pools.

I half recall mentioning this somewhere before, but I'm not sure. But one
fast and compact way to implement power of two buffers is a buddy allocator
(see http://en.wikipedia.org/wiki/Buddy_memory_allocation if you don't know
what I'm referring to, or know it by a different name).

So rather than having, say, three pools for three sizes of pbufs, you have a
single pool, but can efficiently split up and coalesce pbufs. The fact we can
chain pbufs makes this even better. So we can satisfy a 64K allocation with a
64K pbuf, or two 32K pbufs chained together. Of course ethernet frames are
not (usually) a power of two, and although a 1024+512 chain would be close,
it's probably better to keep using a separate pool for that special case.

It's just one possibility anyway.

Since you've already done the work.... Does your rewritten mem.c have the
precise same API as the present mem.c? Is it fairly self-contained? Would it
be possible to have it in the repository named perhaps as mem-alt.c (for
alternative) and users can choose which they build?



    _______________________________________________________

Reply to this item at:

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

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