Bluetooth: Host: Application-managed L2CAP credits

[alwa-nordic]

Android ASHA requires an initial credit count of 8. It is not possible to satisfy this requirement in Zephyr after the change in the L2CAP credit fix. This requirement is vital for interoperability with current software¹.

Footnotes

1. The Android implementation does actually not enforce 8 initial credits, but uses the actual received initial credits in a calculation. This calculation does not deal well with just 1 initial credit. ↩

[alwa-nordic]

To fix this regression, we need to make init_credits significant again. However, init_credits in its current form is an awkward interface because it specifies credits for L2CAP PDUs, but the application provides buffers for SDUs.

The Host could interpret the init_credits field as the number of SDU buffers the application has to give out and manage credits accordingly. Host would keep track of the number of available buffers and give out a credit when a buffer becomes available. This definition of init_credits would be natural for any application that does not have any guarantees from the remote.

But sometimes, the application layer has more information than the Host, and wishes to use credits a specialized fashion. So this is an opportunity define an alternative simplified API for L2CAP that presents the application directly with L2CAP PDUs and allows the application to control the credits explicitly. In the case of ASHA, the specification guarantees that no L2CAP segmentation will occur, so this is perfect. This simplified API would allow applications that have this kind of guarantee to omit compiling in code for L2CAP fragmentation. This API would also benefit applications wish to optimize throughput by making use of some known guarantees or at the cost of reliability.