nordicjm
commented
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.
de-nordic
zephyrbot
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.