linux-kernel - Re: [PATCH v3 1/1] Bluetooth: Prioritize SCO traffic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 3 Apr 2020 16:18:53 -0700
From:   Dave Taht <dave.taht@...il.com>
To:     Abhishek Pandit-Subedi <abhishekpandit@...omium.org>
Cc:     Marcel Holtmann <marcel@...tmann.org>,
        Bluetooth Kernel Mailing List 
        <linux-bluetooth@...r.kernel.org>,
        ChromeOS Bluetooth Upstreaming 
        <chromeos-bluetooth-upstreaming@...omium.org>,
        "David S. Miller" <davem@...emloft.net>,
        Johan Hedberg <johan.hedberg@...il.com>,
        netdev <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Jakub Kicinski <kuba@...nel.org>
Subject: Re: [PATCH v3 1/1] Bluetooth: Prioritize SCO traffic

On Fri, Apr 3, 2020 at 11:11 AM Abhishek Pandit-Subedi
<abhishekpandit@...omium.org> wrote:
>
> Hi Marcel,
>
> Thanks for merging.
>
> I agree that the distinction between SCO/eSCO and ACL/LE is a bit
> concerning for scheduling. I will make some time to revisit this as
> part of Audio improvements we are making.

A) I know nothing of bluetooth.
B) I am unfond of strict priority queues, as they can cause
starvation. My immediate instinct is to reach for a drr++ derived
solution
to give fairness to all flows, and a bit of priority to the ones that
matter most.


>
> Thanks
> Abhishek
>
> Abhishek
>
> On Thu, Apr 2, 2020 at 11:56 PM Marcel Holtmann <marcel@...tmann.org> wrote:
> >
> > 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@...omium.org>
> > > ---
> > >
> > > 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
> >



-- 
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729