Hi Abhishek, > When scheduling TX packets, send all SCO/eSCO packets first, check for > pending SCO/eSCO packets after every ACL/LE packet and send them if any > are pending. This is done to make sure that we can meet SCO deadlines > on slow interfaces like UART. > > If we were to queue up multiple ACL packets without checking for a SCO > packet, we might miss the SCO timing. For example: > > The time it takes to send a maximum size ACL packet (1024 bytes): > t = 10/8 * 1024 bytes * 8 bits/byte * 1 packet / baudrate > where 10/8 is uart overhead due to start/stop bits per byte > > Replace t = 3.75ms (SCO deadline), which gives us a baudrate of 2730666. > > At a baudrate of 3000000, if we didn't check for SCO packets within 1024 > bytes, we would miss the 3.75ms timing window. > > Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@xxxxxxxxxxxx> > --- > > Changes in v3: > * Removed hci_sched_sync > > Changes in v2: > * Refactor to check for SCO/eSCO after each ACL/LE packet sent > * Enabled SCO priority all the time and removed the sched_limit variable > > net/bluetooth/hci_core.c | 106 +++++++++++++++++++++------------------ > 1 file changed, 57 insertions(+), 49 deletions(-) patch has been applied to bluetooth-next tree. However I have been a bit reluctant to apply this right away. I think when this code was originally written, we only had ACL and SCO packets. The world was pretty simple. And right now we also only have two packets types (ignoring ISO packets for now), but we added LE and eSCO as separate scheduling and thus “fake” packet types. I have the feeling that this serialized packet processing will get us into trouble since we prioritize BR/EDR packets over LE packets and SCO over eSCO. I think we should have looked at all packets based on SO_PRIORITY and with ISO packets we have to most likely re-design this. Anyway, just something to think about. Regards Marcel
