Add SPIRAM allocation support to CoAP (IEC-562)

[devunwired]

Is your feature request related to a problem?

The libcoap implementation currently ported by this component relies on HAVE_MALLOC in the port configuration and routes all memory allocations through the default malloc(). This force all memory allocations in this library to be routed to internal memory on ESP32 devices unless CONFIG_SPIRAM_USE_MALLOC is globally enabled for the entire project.

Describe the solution you'd like.

Introduce a KConfig option to enable SPIRAM allocations for the library that disables HAVE_MALLOC in the POSIX configuration and provides proper heap_caps_malloc() overrides for coap_malloc_type(), coap_realloc_type(), and coap_free_type().

Describe alternatives you've considered.

Simply enabling CONFIG_SPIRAM_USE_MALLOC for all projects that use SPIRAM is not a best practice and applications should have the ability to tune the memory allocation strategy for the library components they include.

Additional context.

No response

[mrdeep1]

Does this patch (to the libcoap code in the idf-extra-components/coap/libcoap directory) work for you?

diff --git a/src/coap_mem.c b/src/coap_mem.c
index 7a92fd10..b00d4118 100644
--- a/src/coap_mem.c
+++ b/src/coap_mem.c
@@ -547,6 +547,40 @@ coap_free_type(coap_memory_tag_t type, void *p) {
   k_free(p);
 }

+#elif defined(ESPIDF_VERSION)
+
+#include "esp_heap_caps_init.h"
+
+void
+coap_memory_init(void) {
+}
+
+void *
+coap_malloc_type(coap_memory_tag_t type, size_t size) {
+  void *ptr;
+
+  (void)type;
+  ptr = heap_caps_malloc_prefer(size, 2, MALLOC_CAP_DEFAULT | MALLOC_CAP_SPIRAM,
+                                MALLOC_CAP_DEFAULT | MALLOC_CAP_INTERNAL);
+  return ptr;
+}
+
+void *
+coap_realloc_type(coap_memory_tag_t type, void *p, size_t size) {
+  void *ptr;
+
+  (void)type;
+  ptr = heap_caps_realloc_prefer(p, size, 2, MALLOC_CAP_DEFAULT | MALLOC_CAP_SPIRAM,
+                                 MALLOC_CAP_DEFAULT | MALLOC_CAP_INTERNAL);
+  return ptr;
+}
+
+void
+coap_free_type(coap_memory_tag_t type, void *p) {
+  (void)type;
+  heap_caps_free(p);
+}
+
 #elif defined(HAVE_MALLOC) || defined(__MINGW32__)
 #include <stdlib.h>

If so, I will create a formal patch.

[devunwired]

Thanks for the quick response! I'm not an expert on ESP-IDF patterns, but a few thoughts come to mind.

In principle this approach does address my specific issue, as we need to offload big network buffers to SPIRAM whenever we can. It's akin to what the platform does with configurations like CONFIG_SPIRAM_TRY_ALLOCATE_WIFI_LWIP. However, even that is a configuration option for a reason because I suspect not all users want to defer to SPIRAM as the primary. This creates a new fixed paradigm of "SPIRAM first, always" which can have its own performance liabilities.

Not all devices have SPIRAM enabled, which is why you typically see components checking for things like CONFIG_SPIRAM support first (similar example from another component in this repo). I'm not sure what happens when you call heap_caps_*_prefer() with those options disabled and whether the failure is graceful.

I'm actually a bit surprised patching libcoap was even an option here, but I also would have expected those changes to live in the platform port rather than baked into the library since libcoap provides a platform-configurable memory layer. If the best option is to leave this as a fixed platform define in libcoap, I don't believe the definition you proposed exists (I think it's ESP_IDF_VERSION) but I typically see code checking for ESP_PLATFORM instead for this use case.

I defer to the project maintainers on the best pattern to use, and I'm just grateful to see eyes on this so quickly!

[mrdeep1]

It is possible to have a copy of libcoap's coap_mem.c as a platform port file, but my preference is (as a libcoap maintainer) to maintain the changes in the libcoap code so that the port version does not have to be checked if changes are made to the libcoap code (unlikely in this case, but ....).

I take your point about SPIRAM first. In my qemu emulated environment, there is no SPIRAM, but the testing worked fine. @mahavirj - any comments?

ESPIDF_VERSION is defined in idf-extra-components/coapport/include/coap_config_posix.h which the libcoap code uses for invoking the ESP-IDF specific code requirements.

[mrdeep1]

See #796 for a fix.

[mahavirj]

@mrdeep1 @devunwired

Yes, agree that this is better to be managed at the platform specific port layer.

One example on how we do it for TLS allocations:

1. Upstream component exposes calloc/free hooks and they are mapped to platform specific implementation (Reference)
2. Configurable strategy is provided to choose the allocation strategy - with highlighted risks like SPIRAM without encryption case (Reference)
3. And then the implementation itself is mapped to different heap allocation caps (Reference)