We hope to see RED light; it’s vaporware.
We think we’ll need some sort of fair queuing as well as AQM; SFQ looks good there…
And QFQ looks even better.
I am building a version of both net-next for x86_64 and folding in this patch into cerowrt-rc8
Author: Eric Dumazet firstname.lastname@example.org
Date: Thu Dec 1 11:06:34 2011 +0000
sch_red: fix red_change
Le mercredi 30 novembre 2011 à 14:36 -0800, Stephen Hemminger a écrit :
(Almost) nobody uses RED because they can’t figure it out.
According to Wikipedia, VJ says that:
“there are not one, but two bugs in classic RED.”
RED is useful for high throughput routers, I doubt many linux machines
act as such devices.
I was considering adding Adaptative RED (Sally Floyd, Ramakrishna
Gummadi, Scott Shender), August 2001
In this version, maxp is dynamic (from 1% to 50%), and user only have
setup min_th (target average queue size)
(max_th and wq (burst in linux RED) are automatically setup)
By the way it seems we have a small bug in red_change()
First, if queue is empty, we should call
Second, since we dont use anymore sch->q, but q->qdisc, the test
[PATCH] sch_red: fix red_change()
Now RED is classful, we must check q->qdisc->q.qlen, and if queue
we start an idle period, not end it.
The effect this has on any attempt to classify or schedule packets has
to be seen to be believed.
A 64*k* ‘packet’, followed by a 64 byte packet, is a 1000x1 ratio. Mere packet oriented schedulers, like PFIFO_fast, survive this abuse, but the effect on packets marked background
or priority, over best effort, is correspondingly, um, ‘enhanced’.
Spitting this sort of abuse through a grouping scheduler such as SFB or
SFQ is really bad, as the above effect is magnified. All packet
schedulers that try to do something with bytes rather
than packets, are similarly problematic.
We never figured out how to handle jumbo frames outside the datacenter in the first place.
People doing AQM analysis work work MUST turn off TSO and GSO in order
to get a sane result -
and if you merely turn off TSO, GSO will rise in it’s stead on some devices, and bite you.
(yes, this happened to me)
Even if the device says it’s turning TSO off (because it’s running at sub 100Mbit speeds)
(this was on the e1000e driver, at least, while I was manually setting it below 100Mbit for testing), gso stays on.
The way to turn off both is:
ethtool -K tso off ethtool -K gso off
Author: Michał Mirosław email@example.com
Date: Tue Feb 15 16:59:16 2011 +0000
ethtool: enable GSO and GRO by default
If it were up to me, I’d revert half this commit, with a message like:
“Disable GSO by default”
Disable GSO until the effects of unleashing superpackets on the global
as a whole is better understood by theorists and network designers, and
the Linux scheduler is revised to handle them properly.