When "os_msys_find_pool" searches for an mbuf pool with a given dsize, it simply returns the first pool with a large enough databuffer length to fit the dsize. This same pool is returned, even if there currently are no available mbuf's in the pool.
"os_msys_get" / "os_mbuf_get" then only attempts to get an mbuf from that pool, ignoring any other pools. If that pool is empty, NULL will be returned as if there is no space to allocate the mbuf. This can happen even if there are other pools with larger databuffer lengths with available space to allocate the requested mbuf.
This causes unexpected out-of-memory errors when attempting to allocate mbuf's, even in systems with sufficient free space. For example, on the ESP32 port the default settings provide two mbuf pools, and as a result the second mbuf pool is effectively unused. In spite of this, mbuf allocation failures can still occur with that configuration when the first mbuf pool runs out of space.
When "os_msys_find_pool" searches for an mbuf pool with a given dsize, it simply returns the first pool with a large enough databuffer length to fit the dsize. This same pool is returned, even if there currently are no available mbuf's in the pool.
"os_msys_get" / "os_mbuf_get" then only attempts to get an mbuf from that pool, ignoring any other pools. If that pool is empty, NULL will be returned as if there is no space to allocate the mbuf. This can happen even if there are other pools with larger databuffer lengths with available space to allocate the requested mbuf.
This causes unexpected out-of-memory errors when attempting to allocate mbuf's, even in systems with sufficient free space. For example, on the ESP32 port the default settings provide two mbuf pools, and as a result the second mbuf pool is effectively unused. In spite of this, mbuf allocation failures can still occur with that configuration when the first mbuf pool runs out of space.