how to allocate the MCUmgr buffers dynamically from within the application

[ziv123]

hello Nordic

i am working with nre52840 and nrf52832, with ncs v2.8.0

i am using ble SMP service for transferring data with a central device and for DFU.

currently i am using this config CONFIG_MCUMGR_TRANSPORT_NETBUF_SIZE in my prj.conf so i can have larger buffer to increase throughput.

but using it like so take static memory.

in my app i have a stage when BLE is working and then another stage where BLE is off and its threads, buffers are free for other uses of the app (i manage it with my own heap pool).

i am looking for a way to dynamically allocate this buffer so i can both use larger size (i am limited statically) and to reduce static ram take.

i looked at this config  CONFIG_MCUMGR_TRANSPORT_BT_DYNAMIC_SVC_REGISTRATION

wonder if i have to use it or if setting CONFIG_MCUMGR_TRANSPORT_NETBUF_SIZE = 0 is enough

or maybe i should use this macro some how  - NET_BUF_POOL_DEFINE ?

is there an API i can use to give mcumgr the pointer for the buffer and initialize and close the mcumgr each time i start the BLE and close it 

i am off course open to other way to achieve that if there are

hope to read you soon

best regards

Ziv

[ziv123]

Hi Vidar

Vidar Berg said:

If you need to make changes to the SDK sources, you can also propose your changes upstream in Zephyr by submitting a pull request. If accepted you would not have to maintain a patch for every new release. You may check Zephyr's contribution guidelines for more details about this process.

contribution is one option but what i think of at first is maybe wrap the smp module with my own implementation (we did something similar with spi ) but i wonder which internal mcumgr module should i wrap as my_smp.c and my_smp.h .. if you have any ideas i would love to read your thoughts

Vidar Berg said:

If you were referring to a application defined network buffer (created with NET_BUF_POOL_DEFINE), then I think I understand what you meant by allowing the application to provide a buffer pointer.

what i meant is a buffer i allocate in the app and then i give the net buf the pointer for this buf . is this possible using NET_BUF_POOL_DEFINE macro  to achieve what i need ? .. and do i need to call it 4 times for each of the 4 buffers or give it a pointer for a buff of size = 4_buffer size )??

Vidar Berg said:

you may try with the following configuration and check if that gives you an acceptable upload speed.

CONFIG_BT_L2CAP_TX_MTU=247

CONFIG_BT_BUF_ACL_RX_SIZE=251

CONFIG_MCUMGR_TRANSPORT_NETBUF_SIZE=1220

on one of my central devices i only have ble 4.0/2 so mtu=251 will not work ..

if i change my mcumgr net buf from 704 bytes to 2048 bytes i get between 20-40% increase in throughput (using fs_download we transfer 100kbytes-500kbytes , but we only receive small commands and upload rarely)..  so if i could set large buffer for tx and use the space on the expense of the rx buffers that could really help.  i don't think i'll get the same affect even f i could enable the MTU= 251

hope to read you soon

best regards

Ziv

[ziv123]

??

[ziv123]

well i did manage to make it work by making some changes in the trasfer/smp.c and in the net buf 

i was thinking of contribution but i think the following is a bit of an issue 

i manage to path a pointer from my own pool to replace the static net buff.. but in that way the user might give wrong buff size (not NETBUF_SIZE*NETBUF_COUNT) .. another option is that the user will give an function pointer (according to zephyr required api, like in a callbacks) and then zephyr pools the correct size and it informs the user of the size (though user can check how much is left on his pool by his own) .. does the second approach looks nicer, is it zephyr valid in your view ?

[Vidar Berg]

I'm not sure I understand what approach you took for your solution, especially when you mention having to make changes to the network buffer (are you referring to the actual network buffer implementation)? In any case, if you want to make a contribution, it would better to explain your proposal to the code owners to get their feedback: https://docs.zephyrproject.org/latest/contribute/guidelines.html#pull-requests-and-issues