Understanding memory configuration

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Understanding memory configuration

Andy Pont
Hello,

I’m trying to figure out the memory settings being used by a project that I have inherited.  The lwipopts.h file contains:

#define MEM_USE_POOLS 1
#define MEMP_USE_CUSTOM_POOLS 1
#define MEM_USE_POOLS_TRY_BIGGER_POOL 1

I think this means that it allocates the memory that is defined in lwippools.h which is:

LWIP_MALLOC_MEMPOOL(14, 75)
LWIP_MALLOC_MEMPOOL(6, 225)
LWIP_MALLOC_MEMPOOL(1, 525)
LWIP_MALLOC_MEMPOOL(3, 1540)

I’m not clear what the LWIP_MALLOC_MEMPOOL macro does and how much RAM lwIP is actually trying to allocate.

-Andy.




_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Understanding memory configuration

goldsimon@gmx.de
On 17.09.2018 18:10, Andy Pont wrote:
Hello,

I’m trying to figure out the memory settings being used by a project that I have inherited.  The lwipopts.h file contains:

#define MEM_USE_POOLS 1
#define MEMP_USE_CUSTOM_POOLS 1
#define MEM_USE_POOLS_TRY_BIGGER_POOL 1

I think this means that it allocates the memory that is defined in lwippools.h which is:

Right.


LWIP_MALLOC_MEMPOOL(14, 75)
LWIP_MALLOC_MEMPOOL(6, 225)
LWIP_MALLOC_MEMPOOL(1, 525)
LWIP_MALLOC_MEMPOOL(3, 1540)

I’m not clear what the LWIP_MALLOC_MEMPOOL macro does and how much RAM lwIP is actually trying to allocate.

That macro allocates pools of X elements with Y bytes each.
It allocates (14 * 75) + (6 * 225) + (1 * 525) + (3 * 1540) bytes plus a little offset for administration, so roughly 7,5 kB.


Simon
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Understanding memory configuration

Andy Pont
That macro allocates pools of X elements with Y bytes each.
It allocates (14 * 75) + (6 * 225) + (1 * 525) + (3 * 1540) bytes plus a little offset for administration, so roughly 7,5 kB.
Is that memory being allocated by the linker in either the .data or .bss sections or is it pulled from the heap using malloc()?

They also seem like some really weird combinations of numbers and appear to be one of those things that never got documented anywhere.  Any guesses?

-Andy.


_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Understanding memory configuration

goldsimon@gmx.de
On 17.09.2018 22:20, Andy Pont wrote:
That macro allocates pools of X elements with Y bytes each.
It allocates (14 * 75) + (6 * 225) + (1 * 525) + (3 * 1540) bytes plus a little offset for administration, so roughly 7,5 kB.
Is that memory being allocated by the linker in either the .data or .bss sections

Yes. Just follow the defines:

LWIP_MALLOC_MEMPOOL() -> LWIP_MEMPOOL() -> LWIP_MEMPOOL_DECLARE() -> memp.h lint 95 (git head) instantiates the memory via LWIP_DECLARE_MEMORY_ALIGNED()

Ok, this isn't fun to read from the code, but that's the price for making it configurable ;-)

or is it pulled from the heap using malloc()?

lwIP does *not* use malloc() unless you tell it to!

They also seem like some really weird combinations of numbers and appear to be one of those things that never got documented anywhere.  Any guesses?

No. Well, smallest packets are 60 bytes + 16 bytes for struct pbuf and largest packets are ~1514 bytes + 16 bytes for struct pbuf. Add alignment to this and the smallest and largest pool might make sense...

Simon
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Understanding memory configuration

Andy Pont
Simon wrote...

Yes. Just follow the defines:

LWIP_MALLOC_MEMPOOL() -> LWIP_MEMPOOL() -> LWIP_MEMPOOL_DECLARE() -> memp.h lint 95 (git head) instantiates the memory via LWIP_DECLARE_MEMORY_ALIGNED()
The plot thickens…

I tried to follow this code but couldn’t find some of the defines.  It turns out this project hasn’t been updated and is still running v1.4.x code!  Looking through the .map file from the linker there is a memp_memory in the .bss section which is 23,291 bytes.

Looking through the code, I did discover that the memp_std.h header file doesn’t pickup the values defined in lwipopts.h as the MEMP_USE_CUSTOM_POOLS part isn’t being used and therefore lwippools.h isn’t being included.

It appears that the multiple definitions using LWIP_MEMPOOL() and LWIP_PBUF_MEMPOOL() in memp_std.h are being used.  Swapping in the constants from the options file these become:

LWIP_MEMPOOL(TCPIP_MSG_API,    3,   sizeof(struct tcpip_msg),      "TCPIP_MSG_API”)
LWIP_MEMPOOL(TCPIP_MSG_INPKT, 18,   sizeof(struct tcpip_msg),      "TCPIP_MSG_INPKT”)
LWIP_MEMPOOL(SYS_TIMEOUT,      5,   sizeof(struct sys_timeo),      "SYS_TIMEOUT”)
LWIP_PBUF_MEMPOOL(PBUF,       20,                          0,      "PBUF_REF/ROM”)
LWIP_PBUF_MEMPOOL(PBUF_POOL,  23,                        385,      "PBUF_POOL")

I’ve tried to do some calculations based on the various structure sizes but don’t ever seem to get anywhere near the 23,291 bytes!

-Andy.


_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Understanding memory configuration

goldsimon@gmx.de
On 18.09.2018 09:53, Andy Pont wrote:
[..]
I tried to follow this code but couldn’t find some of the defines.  It turns out this project hasn’t been updated and is still running v1.4.x code!

Ok, that's not good news. You'll find many bugs fixed in the last 6 years!

 Looking through the .map file from the linker there is a memp_memory in the .bss section which is 23,291 bytes.

Try defining MEMP_SEPARATE_POOLS to 1 in lwipopts.h. That should give you many separate pool memories. Maybe that makes it easier for you to see where memory consumption comes from.

Simon
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users