LWIP and Heap

[mikeprotts]

Is there a reason the lwip sys_arch.c (os/various/lwip_bindings/arch/sys_arch.c) code uses Heap memory, rather than Core or Pool allocations? I can see that Static would be tricky.

I'm considering if it's realistic to make these options, but before I spend too long looking at the implications, I thought I'd check to see if the current design is for a specific reason. My first inclination is to create a specific memory pool (probably in lwippools.h) and have a simple Heap or Pool option in lwipopts.h.

Does this sound like a good idea? All thoughts welcome.
Mike

[steved]

If I remember correctly, lwIp grabs a load of memory from the heap on startup, and creates its own memory pools. That's certainly what it looks like from all the configuration options in lwipopts.h. So it might not be too bad a problem to leave it be.

[Giovanni]

If it forms pools, does it ever free memory? if not it could be an advantage to use the core allocator, faster and less wasted memory.

Giovanni

[mikeprotts]

I'm using the lwip memory pools, so that part gets static allocation. These are used by mem_malloc, which can be used from sys_arch.c apart from from sys_sem_new (https://lwip.fandom.com/wiki/Porting_for_an_OS)

There seem to be three areas with heap:
1. semaphore - these should work well from a pool, just need to get an idea of how many needed. The lwip stats suggest 6.
2. mbox - can use mem_malloc and mem_free to use from the lwip pools.
3. thread - I seem to have lwip and tcpip threads, both defined with 1024 stack size in lwipopts.h. Another candidate for a memory pool I think.

A quick test isn't working, it fails to create the tcpip so I'm probably doing something wrong with the memory pools.

[mikeprotts]

If it forms pools, does it ever free memory? if not it could be an advantage to use the core allocator, faster and less wasted memory.

It does free (mem_free) the storage, just returning to the pools I think (https://www.nongnu.org/lwip/2_0_x/group ... __mem.html). I assume these are treated in the usual way as static allocations and reused as needed.

The thread work areas would probably be manageable as static, but pools handle the reuse case well I think. I'll see if I can work out why the tcpip thread creation fails. I can see it's getting a fair way along the process, so I should be able to debug fairly easily:
#0 0x08002730 in chSysHalt (
reason=reason@entry=0x801ac1c <__func__.8439> "chThdCreateSuspendedI")

Time to set some breakpoints I think.

Mike

[Giovanni]

I meant if it returns memory to the OS, if it returns memory to its pools then it is not returned to the OS.

Giovanni

[mikeprotts]

I've got a basic quick hack working. The idea is that if CH_CFG_USE_HEAP is true, then use existing code, otherwise use memory pools and mem_malloc/mem_free as appropriate. I used rather long variable names to make them easy to find in the map.

The threads seem to be additional to lwip_thread, so I only need one in my case, although two are allocated here (I only need TCPIP). For some reason I seem to be allocating 2144 bytes for a 1024 thread working area size.

I need to make the code cleaner to allow variable numbers of thread work areas, but I plan to make them all the same size. I'll see if I can find an easy way to count the threads and largest work area LWIP expects so I can allocate at build time (similar to the test case). Another option would be to add one work area to the pool when requested, and fail if core memory runs out. For my purposes the tcpip thread will always continue so I'll never free the work area.

Semaphores seem to work using the simple memory pool, so I just need to see what lwip setting gives the max number to replace the hard coded 8.

mbox using mem_malloc and mem_free seems fine.

To initialise (note hard coded for 8 semaphores and two threads):

static MEMORYPOOL_DECL(lwip_sys_arch_sem_pool, sizeof(semaphore_t), 4, NULL);
static memory_pool_t lwip_sys_arch_thread_pool;
static semaphore_t sem_pool[8];
static THD_WORKING_AREA(lwip_thread_wa1, THD_WORKING_AREA_SIZE(1024));
static THD_WORKING_AREA(lwip_thread_wa2, THD_WORKING_AREA_SIZE(1024));
void sys_init(void) {
  chPoolLoadArray(&lwip_sys_arch_sem_pool, sem_pool, 8);
  chPoolObjectInit(&lwip_sys_arch_thread_pool, THD_WORKING_AREA_SIZE(1024), NULL);
  chPoolFree(&lwip_sys_arch_thread_pool, lwip_thread_wa1);
  chPoolFree(&lwip_sys_arch_thread_pool, lwip_thread_wa2);
}

Then replace ch*HeapXxxx functions with the equivalent ch*MemoryPoolXxxx ones.

Does this make sense?

To make a patch, is it preferred to have a few lines with ifdefs in a few places (six I think), more duplicated code with separate sections for using heap or not, or use macros to make the code more readable? The attached uses ifdefs where needed.

Mike

[mikeprotts]

Just a note that I'm using lwip-2.0.3-patched and the relevant documentation is at https://www.nongnu.org/lwip/2_0_x/group ... layer.html

Mike

[mikeprotts]

Attached version seems to be working.

I've used the following in lwipopts.h:
#define CH_LWIP_SEM_MAX 8
#define CH_LWIP_THREAD_WA_SIZE 1024
#define CH_LWIP_THREAD_WA_MAX 1

I'm not sure about the naming, especially the last - it's the max number of thread work areas to allocate.

The code will use these to create the semaphore pool of the size given.

The thread work areas are set up in a similar way to the tests (rt_test_root.c, rt_test_sequence_010.c).

There is an assumption that all thread work areas will be the same size. If they're smaller it will probably work, if bigger then it should fail to allocate, so should be picked up readily in testing.

I'm testing on two different boards (STM32F407-DISC1 with STM32F4DIS-BB and Olimex STM32-E407), and will try STM32F429, STM32F746 and STM32F767 Nucleo boards and a custom board (with STM32F767) this week.

Mike

[mikeprotts]

Should this thread be moved to Small Change Requests?

Mike