iproute-3.3 was released march 19th. I've been using the git version for
months now (on 3.2 and 3.3), but I'd done things like rip out esfq (totally
obsolete), q_wrr (does it even work?), and was puzzled as to why it fiddled
so much with pkt_sched.h...
So I'll gladly produce an openwrt patch for iproute-3.3, but would like
answers to the above questions first...
In my case iproute-3.3 is needed for adaptive red, the enhanced sfq, and
sfqred...
I note the sfq enhancements in 3.3 expose a bug in qos-scripts where
'limit' is packets, but is passed as bytes.
commit 18cb809850fb499ad9bf288696a95f4071f73931
Author: Eric Dumazet eric.duma...@gmail.com
Date: Wed Jan 4 14:18:38 2012 +
net_sched: sfq: extend limits
SFQ as implemented in Linux is very limited, with at most 127 flows
and limit of 127 packets. [ So if 127 flows are active, we have one
packet per flow ]
This patch brings to SFQ following features to cope with modern needs.
- Ability to specify a smaller per flow limit of inflight packets.
(default value being at 127 packets)
- Ability to have up to 65408 active flows (instead of 127)
- Ability to have head drops instead of tail drops
(to drop old packets from a flow)
Example of use : No more than 20 packets per flow, max 8000 flows, max
2 packets in SFQ qdisc, hash table of 65536 slots.
tc qdisc add ... sfq \
flows 8000 \
depth 20 \
headdrop \
limit 2 \
divisor 65536
Ram usage :
2 bytes per hash table entry (instead of previous 1 byte/entry)
32 bytes per flow on 64bit arches, instead of 384 for QFQ, so much
better cache hit ratio.
the sfqred support in 3.3, described here:
commit 6987ecf0832d62350ea10432f3f1f7a84c457b81
Author: Eric Dumazet eric.duma...@gmail.com
Date: Fri Jan 20 12:17:43 2012 +0100
sfq: add optional RED on top of SFQ
Adds an optional Random Early Detection on each SFQ flow queue.
Traditional SFQ limits count of packets, while RED permits to also
control number of bytes per flow, and adds ECN capability as well.
1) We dont handle the idle time management in this RED implementation,
since each 'new flow' begins with a null qavg. We really want to address
backlogged flows.
2) if headdrop is selected, we try to ecn mark first packet instead of
currently enqueued packet. This gives faster feedback for tcp flows
compared to traditional RED [ marking the last packet in queue ]
Example of use :
tc qdisc add dev $DEV parent 1:1 handle 10: est 1sec 4sec sfq \
limit 3000 headdrop flows 512 divisor 16384 \
redflowlimit 10 min 8000 max 6 probability 0.20 ecn
qdisc sfq 10: parent 1:1 limit 3000p quantum 1514b depth 127 headdrop
flows 512/16384 divisor 16384
ewma 6 min 8000b max 6b probability 0.2 ecn
prob_mark 0 prob_mark_head 4876 prob_drop 6131
forced_mark 0 forced_mark_head 0 forced_drop 0
Sent 1175211782 bytes 777537 pkt (dropped 6131, overlimits 11007
requeues 0)
rate 99483Kbit 8219pps backlog 689392b 456p requeues 0
In this test, with 64 netperf TCP_STREAM sessions, 50% using ECN enabled
flows, we can see number of packets CE marked is smaller than number of
drops (for non ECN flows)
If same test is run, without RED, we can check backlog is much bigger.
qdisc sfq 10: parent 1:1 limit 3000p quantum 1514b depth 127 headdrop
flows 512/16384 divisor 16384
Sent 1148683617 bytes 795006 pkt (dropped 0, overlimits 0 requeues 0)
rate 98429Kbit 8521pps backlog 1221290b 841p requeues 0
Signed-off-by: Eric Dumazet eric.duma...@gmail.com
On Mon, Apr 2, 2012 at 10:02 AM, Florian Fainelli flor...@openwrt.orgwrote:
Le 02/16/12 14:49, Oliver a écrit :
This patch bumps iproute2 to the latest available version, fixes the
package URL to use kernel.org (as things have now been moved back there)
and also adds ss (socket statistics) to menuconfig.
Signed-off-by: Oliver Smitholipro@8.c.9.b.0.7.4.0.**1.0.0.2.ip6.arpa
Applied in r31179, thanks Oliver!
--
Florian
__**_
openwrt-devel mailing list
openwrt-devel@lists.openwrt.**org openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/**mailman/listinfo/openwrt-develhttps://lists.openwrt.org/mailman/listinfo/openwrt-devel
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
