Design of UDP/IP & 6LoWPAN over BLE with respect to memory management.

[m.spiessens]

Hello,

We're using the UDP/IP/6LoWPAN layers as provided by the nRF5 SDK 15.0.0.0.

After experiencing sporadic issues in communication we have a question regarding the design.

When looking at all references of nrf_mem_reserve() in components/iot/ble_6lowpan & components/iot/ipv6_stack it seems that both the receive and transmit path use this function.

1. The receive path uses it in the ipsp_evt_handler, which to my understanding runs in interrupt context (callback from SoftDevice via observer).
2. The transmit path uses it when performing a iot_pbuffer_allocate(), in main context.
3. To my understanding nrf_mem_reserve() is not a reentrant function, which results in race conditions in the memory manager.

Are my finding correct? If so, how is this design to be used without race conditions?

Best regards,

Mathias

[Håkon Alseth]

Hi,

 

 

Are my finding correct? If so, how is this design to be used without race conditions?

Given that the mutex locking and unlocking is not defined, you are right that this function is not thread safe.

You could wrap the mutex lock / unlock defines around the "CRITICAL_REGION_ENTER()" and "CRITICAL_REGION_EXIT()" macros as a bare minimal implementation.

 

Kind regards,

Håkon

[m.spiessens]

Thanks for the suggestion.

We've chosen a different approach. We modified all 3 layers to have a callback notification when transmission of a packet is complete. This gives us full control over the memory for the transmit path from the application layer. The transmit path now uses an application controlled memory pool and the receive path is the only user of the SDK provided memory manager. We consider this a cleaner solution compared to a mutex since a mutex will result in packet drops in the receive path.