[Starlink] on BQL -- Byte Queue Limits

Dave Taht dave.taht at gmail.com
Mon Jun 21 05:01:26 EDT 2021


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



More information about the Starlink mailing list