Dear reader, I'm not updating these pages anymore. If you have tc or ip related questions, you can post them on the LARTC mailing list.



From help-file :
SFQ queue
CONFIG_NET_SCH_SFQ
  Say Y here if you want to use the Stochastic Fairness Queueing (SFQ)
  packet scheduling algorithm for some of your network devices or as a
  leaf discipline for the CBQ scheduling algorithm (see the top of
  net/sched/sch_sfq.c for details and references about the SFQ
  algorithm).
 
  This code is also available as a module called sch_sfq.o ( = code
  which can be inserted in and removed from the running kernel
  whenever you want). If you want to compile it as a module, say M
  here and read Documentation/modules.txt.

From source-files :
Stochastic Fairness Queuing algorithm.
=======================================

Source:
Paul E. McKenney "Stochastic Fairness Queuing",
IEEE INFOCOMM'90 Proceedings, San Francisco, 1990.

Paul E. McKenney "Stochastic Fairness Queuing",
"Interworking: Research and Experience", v.2, 1991, p.113-131.


See also:
M. Shreedhar and George Varghese "Efficient Fair
Queuing using Deficit Round Robin", Proc. SIGCOMM 95.


This is not the thing that is usually called (W)FQ nowadays.
It does not use any timestamp mechanism, but instead
processes queues in round-robin order.

ADVANTAGE:

- It is very cheap. Both CPU and memory requirements are minimal.

DRAWBACKS:

- "Stochastic" -> It is not 100% fair.
When hash collisions occur, several flows are considered as one.

- "Round-robin" -> It introduces larger delays than virtual clock
based schemes, and should not be used for isolating interactive
traffic from non-interactive. It means, that this scheduler
should be used as leaf of CBQ or P3, which put interactive traffic
to higher priority band.

We still need true WFQ for top level CSZ, but using WFQ
for the best effort traffic is absolutely pointless:
SFQ is superior for this purpose.

IMPLEMENTATION:
This implementation limits maximal queue length to 128;
maximal mtu to 2^15-1; number of hash buckets to 1024.
The only goal of this restrictions was that all data
fit into one 4K page :-). Struct sfq_sched_data is
organized in anti-cache manner: all the data for a bucket
are scattered over different locations. This is not good,
but it allowed me to put it into 4K.

It is easy to increase these values, but not in flight.