os_msys_num_free() and BLE_HS_ENOMEM not making sense

[FrancoisB-HEX]

Checklist

• Checked the issue tracker for similar issues to ensure this is not a duplicate.
• Provided a clear description of your suggestion.
• Included any relevant context or examples.

Issue or Suggestion Description

The bleprph_throughput ESP-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?

1. Why am I periodically seeing BLE_HS_ENOMEM even though the stack is reporting plenty of os_msys_num_free() at that time?
2. What are the underlying mbuf count/sizes that affect BLE_HS_ENOMEM in menuconfig?
3. 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?