Commit cc34eb67 authored by Eric Dumazet's avatar Eric Dumazet Committed by David S. Miller

sch_sfq: revert dont put new flow at the end of flows

This reverts commit d47a0ac7 (sch_sfq: dont put new flow at the end of
flows)

As Jesper found out, patch sounded great but has bad side effects.

In stress situation, pushing new flows in front of the queue can prevent
old flows doing any progress. Packets can stay in SFQ queue for
unlimited amount of time.

It's possible to add heuristics to limit this problem, but this would
add complexity outside of SFQ scope.

A more sensible answer to Dave Taht concerns (who reported the issued I
tried to solve in original commit) is probably to use a qdisc hierarchy
so that high prio packets dont enter a potentially crowded SFQ qdisc.
Reported-by: default avatarJesper Dangaard Brouer <jdb@comx.dk>
Cc: Dave Taht <dave.taht@gmail.com>
Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
parent 122bdf67
...@@ -469,11 +469,15 @@ enqueue: ...@@ -469,11 +469,15 @@ enqueue:
if (slot->qlen == 1) { /* The flow is new */ if (slot->qlen == 1) { /* The flow is new */
if (q->tail == NULL) { /* It is the first flow */ if (q->tail == NULL) { /* It is the first flow */
slot->next = x; slot->next = x;
q->tail = slot;
} else { } else {
slot->next = q->tail->next; slot->next = q->tail->next;
q->tail->next = x; q->tail->next = x;
} }
/* We put this flow at the end of our flow list.
* This might sound unfair for a new flow to wait after old ones,
* but we could endup servicing new flows only, and freeze old ones.
*/
q->tail = slot;
/* We could use a bigger initial quantum for new flows */ /* We could use a bigger initial quantum for new flows */
slot->allot = q->scaled_quantum; slot->allot = q->scaled_quantum;
} }
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment