[X] Checked the issue tracker for similar issues to ensure this is not a duplicate.
[X] Provided a clear description of your suggestion.
[X] Included any relevant context or examples.
Issue or Suggestion Description
The bleprph_throughputESP-IDF example specifies evaluating os_msys_num_free() to be above a certain level before attempting ble_gatts_notify_custom()/ble_gatts_indicate_custom() repeatedly in order to make sure the NimBLE stack still has enough mbufs free for propagating and sending the packet. My issue is that os_msys_num_free() == 103 before the ble_gatts_indicate_custom() function is called, and then it fails with BLE_HS_ENOMEM (rc==6):
W (33746) NimBLE: hex_gatt_svc_transmit: 104 mbufs before allocating indication
W (33746) NimBLE: hex_gatt_svc_transmit: 103 mbufs before sending indication
D (33747) NimBLE: bleprph_gap_event: notify_tx event; conn_handle=1 attr_handle=16 status=6 is_indication=1
W (33747) NimBLE: hex_gatt_svc_transmit: 104 mbufs after sending indication
W (33748) NimBLE: hex_gatt_svc_transmit: Error in sending indication rc = 6
The packet in question above is just 7 octets in length, while the connection MTU is 255 octets. It is clear that os_msys_num_free() is only decreased by the ble_hs_mbuf_from_flat() allocation for the send, and increased after the send call (mbuf consumed) in the case above and in the cases where the send is successful (rc==0) - so that leads me to believe the value reported by os_msys_num_free() does not reflect the state of the BLE Host and controller stacks?
Why am I periodically seeing BLE_HS_ENOMEM even though the stack is reporting plenty of os_msys_num_free() at that time?
What are the underlying mbuf count/sizes that affect BLE_HS_ENOMEM in menuconfig?
How can I check the status of the Host/controller memory stacks before attempting a further send other than attempting a send and getting the error?
Checklist
Issue or Suggestion Description
The
bleprph_throughputESP-IDF example specifies evaluatingos_msys_num_free()to be above a certain level before attemptingble_gatts_notify_custom()/ble_gatts_indicate_custom()repeatedly in order to make sure the NimBLE stack still has enough mbufs free for propagating and sending the packet. My issue is thatos_msys_num_free() == 103before theble_gatts_indicate_custom()function is called, and then it fails withBLE_HS_ENOMEM(rc==6):The packet in question above is just 7 octets in length, while the connection MTU is 255 octets. It is clear that
os_msys_num_free()is only decreased by theble_hs_mbuf_from_flat()allocation for the send, and increased after the send call (mbuf consumed) in the case above and in the cases where the send is successful (rc==0) - so that leads me to believe the value reported byos_msys_num_free()does not reflect the state of the BLE Host and controller stacks?BLE_HS_ENOMEMeven though the stack is reporting plenty ofos_msys_num_free()at that time?BLE_HS_ENOMEMin menuconfig?