I'm sorry to post again.
I just understood LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEX is used in mem.c
for MEM_USE_POOLS=0 and MEM_LIBC_MALLOC=0 (default lwip heap management
from a statically allocated buffer).
What about the reentrancy of memory pools? What happens when
MEM_USE_POOLS=1 and pbuf_free is called in ISR, with or without
LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT? It seems memory pools free is
safe to be used from ISR, because I don't see any protection for them
(differently of lwip default dynamic allocator).
Il 10/10/2022 18:22, Giuseppe Modugno ha scritto:
I'm sorry, I'm using MEM_USE_POOLS=0 *and* MEM_LIBC_MALLOC=1 *and*
mem_clib_free/mem_clib_malloc redefined to a custom buffer-based
memory allocator (derived from mbedtls[1].
Il 10/10/2022 18:15, Giuseppe Modugno ha scritto:
After studying a little more, I understood the problem of using
pbuf_free() in ISR can be solved in two ways:
* by setting LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT to 1 (NO_SYS=0
or 1)
* by using pub_free_callback() in ISR, instead of pbuf_free, only when
NO_SYS=0
The first approach will add protection (disabling/enabling
interrupts) when lwip needs malloc. This isn't a very good approach,
because interrupts would be disabled frequently, but I haven't any
knowledge with RTOS so it's much complex for me to add any to my
project. So I'm working with the following configuration:
* NO_SYS=1 (no OS)
* LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEX=1 (because pbuf_free is called
in ISR)
* MEM_USE_POOLS=0 *and* mem_clib_free/mem_clib_malloc redefined to a
custom buffer-based memory allocator (derived from mbedtls[1])
I suspect this scenario is not safe, because memory allocator from
mbedtls isn't designed to be reentrant from an ISR (as for the memory
pools of lwip when LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEX is set to
1). And for me is very difficult to fix the reentrancy problem of
this allocator.
So I'm thinking the best solution to solve this problem without an OS
is to abandon buffer-based memory allocator and migrate to another
allocator that could be: lwip memory pools (MEM_USE_POOLS=1) or
newlib heap (MEM_USE_POOLS=0 and mem_clib_malloc=malloc and
mem_clib_free=free). What do you suggest?
Anyway I don't understand one thing. Why pbuf_free_callback() can't
be called without an OS? It calls tcpip_try_callback that allocates a
message for tcpip_thread. It shouldn't be difficult to create a list
of pbufs that are waiting to be freed during sys_check_timeouts. What
do you think?
[1]
https://github.com/Mbed-TLS/mbedtls/blob/development/library/memory_buffer_alloc.c
Il 04/10/2022 16:46, Giuseppe Modugno ha scritto:
I started from an example of NXP SDK for LPC546xx MCUs. I'm using
baremetal (NO_SYS=1) and I found the following warning in
enet_ethernetif_lpc.c, function ethernetif_tx_release():
---
#if NO_SYS
#if defined(LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT) &&
LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT
pbuf_free(p);
#else
#error "Bare metal requires LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT=1
because pbuf_free() is being called from an ISR"
#endif /* LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT */
...
---
It seems NXP code calls pbuf_free() inside ISR and this behaviour
must be known to lwip by setting 1 to this macro. However it seems
this macro is checked only in mem.c, if MEM_USE_POOLS is defined.
In my application I don't define MEM_USE_POOLS, so it is set to 0 by
default in opt.h.
Does it mean I can avoid setting
LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEX? I would like to set it to 0,
because of the following warning found in opt.h:
---
* ATTENTION: As you can see from the above description, this leads
to dis-/
* enabling interrupts often, which can be slow! Also, on low
memory, mem_malloc
* can need longer.
---
However NXP code uses #error if this macro is not set, so I suspect
there's a real risk to avoid setting it.
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users