Open de-nordic opened 2 years ago
Describe alternatives you've considered One single static buffer for all mcumgr commands, with no management. Currently could work as mcumg does not support parallel processing SMP requests.
Issue with this is multiple transports which is supported, i.e. if UDP, Bluetooth and shell interfaces are all enabled then 3 concurrent mcumgr commands can be processed at one time and the buffers must not be trumped by one another.
Describe alternatives you've considered One single static buffer for all mcumgr commands, with no management. Currently could work as mcumg does not support parallel processing SMP requests.
Issue with this is multiple transports which is supported, i.e. if UDP, Bluetooth and shell interfaces are all enabled then 3 concurrent mcumgr commands can be processed at one time and the buffers must not be trumped by one another.
Yes, but alternative solution would work with single transport compiled in. Frankly with introduction of zcbor need for some of buffers will be gone.
Hi @nordicjm,
This issue, marked as an Enhancement, was opened a while ago and did not get any traction. It was just assigned to you based on the labels. If you don't consider yourself the right person to address this issue, please re-assing it to the right person.
Please take a moment to review if the issue is still relevant to the project. If it is, please provide feedback and direction on how to move forward. If it is not, has already been addressed, is a duplicate, or is no longer relevant, please close it with a short comment explaining the reason.
@de-nordic you are also encouraged to help moving this issue forward by providing additional information and confirming this request/issue is still relevant to you.
Thanks!
Is your enhancement proposal related to a problem? Please describe. Various mcumgr SMP request processing handlers often need to allocate buffers for incoming data for example echo, file download/upload for file chunk, shell for command line, and so on. Each handler usually does it on it's own by either allocating buffer on stack of a handler function or by having some predefined static buffer. This cause some problems: 1) in case of stack allocation in makes it hard to predict how much stack in reality is required; even though handlers are not called in parallel handler with largest stack requirement impacts how much stack is needed, which needs to be configured at compile time and may be hit or miss causing board to sometimes fail with stack overflow; 2) in case of static allocation it means that each enabled handler will add to preallocated, at compile time, static RAM.
Describe the solution you'd like mcumgr specific, common for all handlers memory manager. Such memory manager should cover largest possible buffer size requirements and optionally multiple buffer allocations, Such manager would be easier to tune for mcumgr, would allow to easier control, at compile time, how much RAM will be taken and would prevent significant increases of RAM requirements with additions of mcumgr commands.
Describe alternatives you've considered One single static buffer for all mcumgr commands, with no management. Currently could work as mcumg does not support parallel processing SMP requests.