SDC HCI driver, no available ACL buffers may block other buffers

[ahmed-dl]

Dear Nordic Team,

I'm currently working on an application that uses ACL and ISO to transmit data between 2 devices.

ACL is used for transmitting operations that are then performed on the receiving device and ISO is used for transmitting time sensitive data.

Sometimes the receiving application may block the receiving ACL data for a few seconds (which leads to no more ACL buffers), which is okay and expected.
However, I would expect that while the ACL data is blocked, I still may be able to receive data from ISO.
Unfortunately, this is not the case and I assume that this use case should work.

After some investigation into the issue, I saw that the Zephyr SDC HCI driver calls `sdc_hci_get` to get data from the controller and then tries to obtain the buffer until it is available. If the data is now for e.g. ACL data and we have no more available ACL buffers, we also block the reception of ISO data (and also regular HCI events).

I've seen that for sending there are multiple function calls (`sdc_hci_data_put` and `sdc_hci_iso_data_put`) and in previous SDC versions there were also different get functions for obtaining data from the controller, but this was unfortunately removed. 

Would it be able to again get multiple SDC get functions instead of the single one, or are there internal limitations (e.g. single HCI queue) that do not allow for splitting these?

Thank you.

nRF SDK v3.2.0

[Hieu]

Hi ahmed-dl,

I believe that the behavior you observe aligns with the nature of ACL and ISO links. ACL links require strict timing, while ISO links are loss tolerant. Therefore, it makes sense that ACL links are given priority in processing, more so when the ACL buffers are full.

If I understand right, the bottle neck you are having is in the application side, and the congestion situation is temporary. In that case, may I suggest creating enough application side buffers so that ACL data is consumed and ISO data can be retrieved?

As for the API request for the SDC, if you wish, I can only review it against the Bluetooth Spec and create a feature request if there is no conflict. However, I can't make any promise it will be accepted or how quickly it would be processed.

Hieu

[ahmed-dl]

I understand your point, but the other way around the problem also exists. If I block the ISO buffer processing and I have no more host ISO buffers, then I also block the reception of ACL data.

We already have a lot of buffers, but due to external factors these congestion situations may take longer and therefore we run into these problematic situations.

I would appreciate such a feature request if possible, thank you.

BR

[Hieu]

in previous SDC versions there were also different get functions for obtaining data from the controller, but this was unfortunately removed. 

I couldn't find the past version of SDC API that has separated get functions for ACL and ISO. Could you please give me some details?

BR,

Hieu

[ahmed-dl]

Please look at the sdc_hci.h in an older version. Here we could see that sdc_hci_data_get and sdc_hci_evt_get were present. And looking at an older version of HCI driver, we could see that there was an recv_thread that called fetch_and_process_hci_evt (sdc_hci_evt_get) and fetch_and_process_acl_data (sdc_hci_data_get). ISO was not yet supported back then I think.

Thanks.

[Hieu]

Then it seems there was not a dedicated API for ISO before then.

I can relay this feature request. However, as mentioned, I cannot make any promise on whether it will be accepted; and even if it is, I can't comment on when it will be done. My apology for this inconvenience, but that is the limit of my scope.

If you want any further comment, then you will have to contact with our sales team.