esp-wifi: Custom allocation functions only works with global allocator.

[raphaelhetzel]

Bug description

While the API (esp_wifi_free_internal_heap and esp_wifi_allocate_from_internal_ram) seem like the allocations are permanent (I assumed this was using some sort of arena internally), esp-wifi still calls alloc::alloc::dealloc on the regions it got from that pool (https://github.com/esp-rs/esp-hal/blob/main/esp-wifi/src/compat/malloc.rs#L36). If this region is not the global allocator, this will ultimately lead to the wifi stack running out of memory.

I guess this could be fixed by also adding an esp_wifi_free_from_internal_ram function.

Environment

Should be a general problem and exists on the current main.
Was tested on an ESP32S3.

[bjoernQ]

Thanks

Currently all allocations made by drivers itself are done in internal memory. We can relax that since the drivers use different functions for internal-only memory and memory which is allowed to live in external RAM.

The reason we don't just use the global allocator is that the APIs don't allow us to specify "memory properties".

In the future we might change the mechanism to use a non-global Allocator for that (#2192)

I see how it would be useful to have esp_wifi_free_from_internal_ram but while the drivers call specific functions to allocate from internal or any RAM, they always only call one function to free the memory

[raphaelhetzel]

In my case I wanted to isolate the wifi-stacks memory pool in order to get the system deterministic (my application should have a "static" (guess true static allocation is impossible for idf-based things like the wifi stack) core and dynamic applications, mostly placed on the remaining ram / psram. I actually just used two instances of esp alloc for that.

The API didn't look like there was that difference between internal/external (altough I am not sure if this is scoped to the wifi stack or used by any c code calling malloc), so if thats not an easy thing to split this might be solved using a small comment in the documentation.

But in the end, I can work around this.

Guess the true Rust-based approach would be to make this allocator aware (using the experimental allocator_api).

[bjoernQ]

so if thats not an easy thing to split this might be solved using a small comment in the documentation.

I agree - the documentation there is lacking

Guess the true Rust-based approach would be to make this allocator aware (using the experimental allocator_api).

That would be the goal - but we don't want to force users into nightly so the current situation is a workaround until that is available

[raphaelhetzel]

but we don't want to force users into nightly

Yeah, that is understandable.

Thanks for the quick reply.