On Mon, 2006-10-23 at 13:42 +0100, Jonathan Larmour wrote: > Goldschmidt Simon wrote: > > maybe a better solution might be to implement > > mem_malloc() as different pools and leave the PBUF_RAM implementation > > since it would be allocated from pools then. > > Note that despite what's implied in that bug, IMHO you can't actually let > it be the current pbuf_alloc(..., PBUF_POOL), otherwise if you use up all > the pbufs with TX data, you won't have room for any RX packets, including > the TCP ACK packets which will allow you to free some of your TX packets. > So either RX and TX packets should be allocated from different pools, or > there should be a low water mark on the pool for TX allocations in order to > reserve a minimum number of packets for RX.
The later would be my preference as it is much more efficient on memory usage where you have unidirectional traffic (which is, to a first approximation, quite common for bulk transfers). > One good solution if using 2^n sized pools is to use a buddy allocator[1] > to divide up larger contiguous space, so it may not be as wasteful as you > think. One difference with a normal buddy allocator is that a normal one > would normally e.g. return a 2Kbyte buffer if you request 1025 bytes. An > lwIP implementation could work for maximum efficiency instead and allocate > that as a 1024 byte buffer plus a 64 byte buffer (or whatever the lowest > granularity would be) chained together. I think that would definitely be the only way such a change would be acceptable given that lwIP tries to have a low memory footprint, and indeed it's the only way I'd even though of it being done. > But all this would be a non-trivial bit of coding so I'm sure people would > be grateful if you have time to do it Exactly. These day changes to lwIP generally only get included by someone who uses it taking the time to write the code - the maintainers do their best to maintain it and fix bugs, but a rework such as this is unlikely to ever reach the top of their list of things to do. > I could also believe the result will use more a fair bit more code space > than the present mem_malloc. Certainly true. Kieran _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
