I notice one other small problem with my modified version of SFQ. The fact that packets can be dropped at dequeue time is incompatible with the way HTB (and probably CBQ and others modeled on it) keep statistics. When I fill a low rate queue causing packets to expire and be dropped at dequeue I get interesting statistics like this: This is my variant of SFQ qdisc plfq 8016: dev eth1 ... Sent 17468 bytes 166 pkts (dropped 833, overlimits 0) ... qdisc htb 1: dev eth1 r2q 10 default 2 dcache 0 deq_util 1/1000000 deq_rate 0 trials_per_deq 0 dcache_hits 0 direct_packets 0 Sent 32626 bytes 309 pkts (dropped 690, overlimits 1126) backlog 143p Note that plfq, which is inside of htb, thinks it has dropped more packets than htb has. The reason is that htb considers a packet to be "sent" when it's enqueued. I notice in retrospect that even with current SFQ, the statistics are not correct. The reason is that it's possible to successfully enqueue packet#1 (at which point HTB adds its length to the number of bytes "sent)", then fail to enqueue packet#2. But within SFQ this "failure" might really mean that packet#2 was accepted to be sent later and it displaced packet#1. It happens that this "replacement" keeps the packet count correct, but not the byte count. One can imagine another version of SFQ that, instead of limiting the number of packets in the queue, limits the number of bytes. In that case the number of packets would not be correct either. I think that HTB (and other classful qdiscs) should count the number of bytes and packets "sent" when they're dequeued, not when they're enqueued. It's an interesting point that, at the moment, I don't see any way for the classful qdisc to know how many packets and bytes were dropped. However, I think it would be useful to know instead how many were passed to enqueue. Then you'd get a report like Enqueued 32626 bytes 309 pkts, Dequeued 17468 bytes 166 pkts where the difference is the sum of what's been dropped and what's still in the queue.
