Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Add menuconfig option to prefer PSRAM when allocating outbox buffers. (IDFGH-8993) #242

Closed
not-my-real-name opened this issue Dec 19, 2022 · 8 comments

Comments

@not-my-real-name
Copy link

Hi Everyone,

I have a feature request for the MQTT library. I am using this library with PSRAM on an ESP32 WROVER (with IDF4.4). I've noticed that the default outbox implementation utilises a linked list where messages waiting to be published are copied into a RAM buffer before being sent. The buffers are allocated using a malloc() call. Could you consider adding a config option to prefer allocating these buffers from PSRAM (e.g. heap_caps_malloc_prefer()) instead of using a basic malloc call? Even if the list objects are kept in internal RAM, just moving the payload buffers would make a huge difference.

I can shift my large message buffers (e.g. 10-50KB) to PSRAM, but I still need to have an equal sized amount of internal RAM free.

An alternative/additional solution would be to add a zero-copy publish command that takes a buffer pointer and a callback and calls the callback when the buffer is safe to release/free (ideally include a result code for the publish as well). This is obviously a much larger change, but it would execute faster if you could get rid of the extra copy step.

Link to topic for original discussion:
https://esp32.com/viewtopic.php?f=13&t=31122

@github-actions github-actions bot changed the title Feature request: Add menuconfig option to prefer PSRAM when allocating outbox buffers. Feature request: Add menuconfig option to prefer PSRAM when allocating outbox buffers. (IDFGH-8993) Dec 19, 2022
@euripedesrocha
Copy link
Collaborator

Hi @not-my-real-name, thanks for the suggestion. We have an ongoing work on the outbox, and we'll introduce this changes also.

@not-my-real-name
Copy link
Author

I thought I would check back in and see if there as been any update on this?

I've forked this library and done my own small change that adds an option for PSRAM malloc.

2e30eb5

This also requires changes to the Kconfig file for this component but that is in the parent repository.

	config MQTT_PSRAM_OUTBOX
        bool "Allow PSRAM outbox buffers"
        default n
        help
            Set to true if you want to allocate message buffers for pending MQTT outbox items from the external
			PSRAM. This is especially useful when sending messages with large payloads as it conserves internal 
			RAM.

@euripedesrocha
Copy link
Collaborator

@not-my-real-name this was introduced to esp-mqtt a while ago in 2c71f9e. Recently we updated to idf master, and we are in the process to backport it to 5.1

@not-my-real-name
Copy link
Author

Thanks. Sorry, I did look for it but can't have looked well enough!

@not-my-real-name
Copy link
Author

Oh, I know why I missed it. I think the implementation is incorrect. The wrong memory allocation has been changed.

This only changes where the list item is held. I think it makes sense to keep this from a normal calloc in normal memory as that is probably faster and the object is small. So this should revert:

outbox_item_handle_t item = heap_caps_calloc(1, sizeof(outbox_item_t), MQTT_OUTBOX_MEMORY);

The external malloc should be here:

item->buffer = malloc(message->len + message->remaining_len);

item->buffer = heap_caps_malloc(message->len + message->remaining_len, MQTT_OUTBOX_MEMORY);

@euripedesrocha
Copy link
Collaborator

@not-my-real-name you are correct. I'll take another look.

@bmedici
Copy link

bmedici commented Jul 22, 2024

Hi, do you have any news on this ?

@euripedesrocha
Copy link
Collaborator

@bmedici the feature is implemented, and it is available. If you have any problems with it, I would ask you to please open a new issue explaining your problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants