Thank you very much for explanation. Light has been throwed now :) The only thing remained in a shadow is combination MEM_USE_POOLS + MEMP_USE_CUSTOM_POOLS. As I understand MEMP_USE_CUSTOM_POOLS have only one exclusive dependency on MEM_USE_POOLS. Also you said directly that user have to enable second one if enables first one. Why not remove this redundant option ? They have equal meaning. Or maybe it's possible to have MEMP_USE_CUSTOM_POOLS enabled without MEM_USE_POOLS ?
This married couple has another issue I asked about in thread "System objects management (semaphores, mailboxes, mutexes, threads, etc.): pool size ?" To use MEMP pool efficiently in sys_arch I need to know a kind of mailbox in sys_mbox_new() rather then size. I cannot reverse-determine kind from size, because sizes are not different generally. At the same time, pool-based mem_malloc won't help in case when mailbox itself allocated in RTOS memory and RTOS return just pointer (sys_mbox_t) of fixed size. In such a way, I have to implement own independed pool mechanism included in port for that RTOS. > jblackarty <[email protected]> wrote: >> It's totally unclear are mem and memp independent mechanisms, or mem >> utilizes memp, or memp uses mem, or they are cross-references each >> other ? Custom pools are part of pools (memp), or pools are part of >> custom pools ? >> >> There are complicated set of options: > Yes, that's the nature of lwIP being adjustable to the needs of > your (possibly small or otherwise restricted) target hardware. > I'll start explaining the 'standard' options. Basically, lwIP has 2 > strategies for memory allocation: pools and a heap. The heap is > mainly only used for outgoing PBUFs allocated with the type > PBUF_RAM. Then there is one memory pool per structure type: >> MEMP_NUM_*, > These control the amount of structures of that type (e.g. > MEMP_NUM_UDP_PCB sets the amount of available udp connections). >> MEM_SIZE, > This is the size of the heap (used for PBUF_RAM allocation). >> PBUF_POOL_SIZE. > As it says in opt.h (did you read that file???), the number of > pbufs in the pbuf pool (where PBUF_POOL_BUFSIZE controls the size of > these pbufs). The pbufs from the pool are of type PBUF_POOL. > Nnow to the more advanced options: >> MEM_LIBC_MALLOC, > Some people don't care about the danger of heap fragmentation and > want to use the C library's malloc/free functions instead of the > lwIP-internal memory allocation (if only to save code because the C > library's functions are included in their binary, anyway). Set this to 1 to > do so. >> MEMP_MEM_MALLOC, > This is mainly only usefule with the previous option: when set to > 1, memp pool allocation uses the heap allocation functions (this was > introduced to let memp allocations be using the C library's malloc. >> MEM_USE_POOLS, > This is the other way round than the previous: when you're scared > of heap fragmentation, let mem_malloc() allocate from specific > pools. The size of these pools (and the number of entries in them) > needs to be configured *and* you have to enable the next option. >> MEMP_USE_CUSTOM_POOLS, > This enables custom memp pools. They are needed for the previous > option but you can also define more pools, for example to put your semaphores > or mboxes into. >> How they related to each other ? >> For MEMP_MEM_MALLOC a comment says "Use mem_malloc/mem_free instead of >> the lwip pool allocator.". But mem_malloc is part of pool mechanisms. > No, memp_malloc (not the 'p') allocates from pools, mem_malloc allocates from > the heap! >> How it can be disabled ? Also "Especially useful with MEM_LIBC_MALLOC >> ..." confuses. Isn't libc allocator completely disables pool mechanism >> ? These options must exclude each other. > No, why should they??? >> Is it possible disable allocating standard structs in pool at all ? > Yes, see above >> Does it makes sense configure MEMP_NUM_* options if MEM_LIBC_MALLOC >> enabled ? > No. >> MEM_SIZE includes only pool of standart structures or also pbufs pool ? > None of them. It controls the heap size and has nothing todo with pools. >> Questions may be continued indefinitely. > Is that so? >> lwip source code doesn't >> describe architecture because it's heavily stuffed with complex macro >> conditions >> nested each in other. > lwIP relies on people's contribution, so if there's anything > missing for a beginner, please don't hesitate to contribute. Writing > something on the wiki is the easiest part to help future beginners getting > started faster. >> "Custom_memory_pools" article on wiki doesn't >> help too because it doesn't describe whole memory mechanism completely. > Right, it only describes how to enable custom memory pools. I guess > it's rather targeted at people already using lwIP as a guideline of how to > get custom pools running. >> I will appreciate if someone throw light upon this subject. > Hope I did. :-) > Simon _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
