From: Dave Taht <dave.taht@gmail.com>
To: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] on BQL -- Byte Queue Limits
Date: Mon, 21 Jun 2021 02:03:16 -0700 [thread overview]
Message-ID: <CAA93jw7SqdHGM1VJCPsrGPL8sRNz2b6i3NPBzitYKQ=_MeZ78A@mail.gmail.com> (raw)
In-Reply-To: <CAA93jw5GR6ACHjUWrAC=R0oRBKNAuVu-bNY5mc4ab3n2F5crAg@mail.gmail.com>
oops: broadcom preso here: http://www.taht.net/~d/broadcom_aug9_2018.pdf
On Mon, Jun 21, 2021 at 2:01 AM Dave Taht <dave.taht@gmail.com> wrote:
>
> Have been in the linux kernel since version 3.3, but it requires about
> 6 lines of calls within each
> device driver to effectively enable. What BQL does is supply one
> interrupt's worth of data backpressure
> to the overlying queuing discipline (qdisc) to do more magic, where we
> had first put latency sensitive
> qdiscs like fq_codel. At 100Mbit (without TSO), this is typically 3-8k
> of data living on the device tx ring
> where prior to the development of BQL and awareness of bufferbloat as
> a problem, this had hit numbers as large as 64k*4096...
>
> Anything that can supply backpressure to the qdisc before it enters the device
> driver's ring buffers can be used however - high/low watermarks are
> still pretty common - but because
> BQL uses byte limits, rather than variably sized (64-64k) packet
> limits, and bytes == time on most media, BQL is the best thing going
> "down there" in the Linux kernel. BSD has no equivalent functionality
> as yet.
>
> Linux AQL - Airtime queue limits - is closely related, but for wifi.
>
> There is an extension, called XMIT_MORE that helps on batchier
> transfers from the qdisc.
>
> We never wrote BQL up in "bufferbloat and beyond" because it was
> already well established when toke
> started his MsC thesis, even though it was the breakthrough algorithm
> that made all our debloating
> work feasible.
>
> There's a link to a paper and a tutorial about BQL in this old
> presentation to broadcom here:
>
> And a detailed, often ranty but chock full of links to other good old
> papers, over here:
> https://conferences.sigcomm.org/sigcomm/2014/doc/slides/137.pdf
>
> IPQ8014 does appear to have a BQL'd ethernet driver, but haven't
> looked deeply yet.
>
> PS Writing this stuff up because this list is largely a new audience
> for the bufferbloat related APIs in
> the linux kernel
>
> --
> Latest Podcast:
> https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/
>
> Dave Täht CTO, TekLibre, LLC
--
Latest Podcast:
https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/
Dave Täht CTO, TekLibre, LLC
prev parent reply other threads:[~2021-06-21 9:03 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-21 9:01 Dave Taht
2021-06-21 9:03 ` Dave Taht [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/starlink.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAA93jw7SqdHGM1VJCPsrGPL8sRNz2b6i3NPBzitYKQ=_MeZ78A@mail.gmail.com' \
--to=dave.taht@gmail.com \
--cc=starlink@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox