Re: [lwip-users] memory pools question

[jblackarty]

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 <address@hidden> 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