Happy new year !
This makes no sense to me for such a low amount of flows, SFQ should
perform the same than QFQ :)
You dont find out why it is so.
Please try following patch :
[PATCH net-next] sch_sfq: dont put new flow at the end of flows
SFQ enqueue algo puts a new flow _behind_ all pre-existing flows in the
circular list. In fact this is probably an old SFQ implementation bug.
100 Mbits = ~8333 full frames per second, or ~8 frames per ms.
With 50 flows, it means your "new flow" will have to wait 50 packets
being sent before its own packet. Thats the ~6ms.
We certainly can change SFQ to give a priority advantage to new flows,
so that next dequeued packet is taken from a new flow, not an old one.
Reported-by: Dave Taht <redacted>
Signed-off-by: Eric Dumazet <redacted>
---
@@ -366,11 +366,11 @@ sfq_enqueue(struct sk_buff *skb, struct Qdisc *sch)if(slot->qlen==1){/* The flow is new */if(q->tail==NULL){/* It is the first flow */slot->next=x;+q->tail=slot;}else{slot->next=q->tail->next;q->tail->next=x;}-q->tail=slot;slot->allot=q->scaled_quantum;}if(++sch->q.qlen<=q->limit)
Happy new year !
This makes no sense to me for such a low amount of flows, SFQ should
perform the same than QFQ :)
You dont find out why it is so.
Please try following patch :
[PATCH net-next] sch_sfq: dont put new flow at the end of flows
SFQ enqueue algo puts a new flow _behind_ all pre-existing flows in the
circular list. In fact this is probably an old SFQ implementation bug.
100 Mbits = ~8333 full frames per second, or ~8 frames per ms.
With 50 flows, it means your "new flow" will have to wait 50 packets
being sent before its own packet. Thats the ~6ms.
We certainly can change SFQ to give a priority advantage to new flows,
so that next dequeued packet is taken from a new flow, not an old one.
Reported-by: Dave Taht <redacted>
Signed-off-by: Eric Dumazet <redacted>
---
@@ -366,11 +366,11 @@ sfq_enqueue(struct sk_buff *skb, struct Qdisc *sch)if(slot->qlen==1){/* The flow is new */if(q->tail==NULL){/* It is the first flow */slot->next=x;+q->tail=slot;}else{slot->next=q->tail->next;q->tail->next=x;}-q->tail=slot;slot->allot=q->scaled_quantum;}if(++sch->q.qlen<=q->limit)
From: Eric Dumazet <hidden> Date: 2012-01-02 05:08:01
Le lundi 02 janvier 2012 à 05:55 +0100, Eric Dumazet a écrit :
I tested this patch with a 50 concurrent netperf workload, and indeed
this fixes the problem for me.
# ping 192.168.20.108
PING 192.168.20.108 (192.168.20.108) 56(84) bytes of data.
64 bytes from 192.168.20.108: icmp_req=1 ttl=64 time=0.021 ms
64 bytes from 192.168.20.108: icmp_req=2 ttl=64 time=0.011 ms
64 bytes from 192.168.20.108: icmp_req=3 ttl=64 time=0.011 ms
64 bytes from 192.168.20.108: icmp_req=4 ttl=64 time=0.010 ms
64 bytes from 192.168.20.108: icmp_req=5 ttl=64 time=0.010 ms
64 bytes from 192.168.20.108: icmp_req=6 ttl=64 time=0.010 ms
Oops, pinging a real machine, not myself I get more realistic numbers :)
# ping -c 20 192.168.20.112
PING 192.168.20.112 (192.168.20.112) 56(84) bytes of data.
64 bytes from 192.168.20.112: icmp_req=1 ttl=64 time=0.488 ms
64 bytes from 192.168.20.112: icmp_req=2 ttl=64 time=0.214 ms
64 bytes from 192.168.20.112: icmp_req=3 ttl=64 time=0.696 ms
64 bytes from 192.168.20.112: icmp_req=4 ttl=64 time=0.135 ms
64 bytes from 192.168.20.112: icmp_req=5 ttl=64 time=0.110 ms
64 bytes from 192.168.20.112: icmp_req=6 ttl=64 time=0.401 ms
64 bytes from 192.168.20.112: icmp_req=7 ttl=64 time=0.378 ms
64 bytes from 192.168.20.112: icmp_req=8 ttl=64 time=0.384 ms
64 bytes from 192.168.20.112: icmp_req=9 ttl=64 time=1.03 ms
64 bytes from 192.168.20.112: icmp_req=10 ttl=64 time=0.439 ms
64 bytes from 192.168.20.112: icmp_req=11 ttl=64 time=0.126 ms
64 bytes from 192.168.20.112: icmp_req=12 ttl=64 time=0.093 ms
64 bytes from 192.168.20.112: icmp_req=13 ttl=64 time=0.834 ms
64 bytes from 192.168.20.112: icmp_req=14 ttl=64 time=0.696 ms
64 bytes from 192.168.20.112: icmp_req=15 ttl=64 time=0.776 ms
64 bytes from 192.168.20.112: icmp_req=16 ttl=64 time=0.215 ms
64 bytes from 192.168.20.112: icmp_req=17 ttl=64 time=0.262 ms
64 bytes from 192.168.20.112: icmp_req=18 ttl=64 time=0.554 ms
64 bytes from 192.168.20.112: icmp_req=19 ttl=64 time=0.373 ms
64 bytes from 192.168.20.112: icmp_req=20 ttl=64 time=0.666 ms
--- 192.168.20.112 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19000ms
rtt min/avg/max/mdev = 0.093/0.443/1.035/0.264 ms
From: Eric Dumazet <hidden> Date: 2012-01-02 05:27:14
Le lundi 02 janvier 2012 à 06:07 +0100, Eric Dumazet a écrit :
quoted hunk
Le lundi 02 janvier 2012 à 05:55 +0100, Eric Dumazet a écrit :
quoted
I tested this patch with a 50 concurrent netperf workload, and indeed
this fixes the problem for me.
# ping 192.168.20.108
PING 192.168.20.108 (192.168.20.108) 56(84) bytes of data.
64 bytes from 192.168.20.108: icmp_req=1 ttl=64 time=0.021 ms
64 bytes from 192.168.20.108: icmp_req=2 ttl=64 time=0.011 ms
64 bytes from 192.168.20.108: icmp_req=3 ttl=64 time=0.011 ms
64 bytes from 192.168.20.108: icmp_req=4 ttl=64 time=0.010 ms
64 bytes from 192.168.20.108: icmp_req=5 ttl=64 time=0.010 ms
64 bytes from 192.168.20.108: icmp_req=6 ttl=64 time=0.010 ms
Oops, pinging a real machine, not myself I get more realistic numbers :)
# ping -c 20 192.168.20.112
PING 192.168.20.112 (192.168.20.112) 56(84) bytes of data.
64 bytes from 192.168.20.112: icmp_req=1 ttl=64 time=0.488 ms
64 bytes from 192.168.20.112: icmp_req=2 ttl=64 time=0.214 ms
64 bytes from 192.168.20.112: icmp_req=3 ttl=64 time=0.696 ms
64 bytes from 192.168.20.112: icmp_req=4 ttl=64 time=0.135 ms
64 bytes from 192.168.20.112: icmp_req=5 ttl=64 time=0.110 ms
64 bytes from 192.168.20.112: icmp_req=6 ttl=64 time=0.401 ms
64 bytes from 192.168.20.112: icmp_req=7 ttl=64 time=0.378 ms
64 bytes from 192.168.20.112: icmp_req=8 ttl=64 time=0.384 ms
64 bytes from 192.168.20.112: icmp_req=9 ttl=64 time=1.03 ms
64 bytes from 192.168.20.112: icmp_req=10 ttl=64 time=0.439 ms
64 bytes from 192.168.20.112: icmp_req=11 ttl=64 time=0.126 ms
64 bytes from 192.168.20.112: icmp_req=12 ttl=64 time=0.093 ms
64 bytes from 192.168.20.112: icmp_req=13 ttl=64 time=0.834 ms
64 bytes from 192.168.20.112: icmp_req=14 ttl=64 time=0.696 ms
64 bytes from 192.168.20.112: icmp_req=15 ttl=64 time=0.776 ms
64 bytes from 192.168.20.112: icmp_req=16 ttl=64 time=0.215 ms
64 bytes from 192.168.20.112: icmp_req=17 ttl=64 time=0.262 ms
64 bytes from 192.168.20.112: icmp_req=18 ttl=64 time=0.554 ms
64 bytes from 192.168.20.112: icmp_req=19 ttl=64 time=0.373 ms
64 bytes from 192.168.20.112: icmp_req=20 ttl=64 time=0.666 ms
--- 192.168.20.112 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19000ms
rtt min/avg/max/mdev = 0.093/0.443/1.035/0.264 ms
And after disabling TSO (as you did in your tests) I get this :
(Note my link is Gigabit, so I had to install a HTB shaper to 100Mbit to
mimic your workload)
# ping -c 20 192.168.20.112
PING 192.168.20.112 (192.168.20.112) 56(84) bytes of data.
64 bytes from 192.168.20.112: icmp_req=1 ttl=64 time=0.113 ms
64 bytes from 192.168.20.112: icmp_req=2 ttl=64 time=0.153 ms
64 bytes from 192.168.20.112: icmp_req=3 ttl=64 time=0.092 ms
64 bytes from 192.168.20.112: icmp_req=4 ttl=64 time=0.095 ms
64 bytes from 192.168.20.112: icmp_req=5 ttl=64 time=0.176 ms
64 bytes from 192.168.20.112: icmp_req=6 ttl=64 time=0.159 ms
64 bytes from 192.168.20.112: icmp_req=7 ttl=64 time=0.169 ms
64 bytes from 192.168.20.112: icmp_req=8 ttl=64 time=0.122 ms
64 bytes from 192.168.20.112: icmp_req=9 ttl=64 time=0.148 ms
64 bytes from 192.168.20.112: icmp_req=10 ttl=64 time=0.123 ms
64 bytes from 192.168.20.112: icmp_req=11 ttl=64 time=0.186 ms
64 bytes from 192.168.20.112: icmp_req=12 ttl=64 time=0.210 ms
64 bytes from 192.168.20.112: icmp_req=13 ttl=64 time=0.142 ms
64 bytes from 192.168.20.112: icmp_req=14 ttl=64 time=0.134 ms
64 bytes from 192.168.20.112: icmp_req=15 ttl=64 time=0.092 ms
64 bytes from 192.168.20.112: icmp_req=16 ttl=64 time=0.187 ms
64 bytes from 192.168.20.112: icmp_req=17 ttl=64 time=0.123 ms
64 bytes from 192.168.20.112: icmp_req=18 ttl=64 time=0.159 ms
64 bytes from 192.168.20.112: icmp_req=19 ttl=64 time=0.142 ms
64 bytes from 192.168.20.112: icmp_req=20 ttl=64 time=0.207 ms
From: David Miller <davem@davemloft.net> Date: 2012-01-03 17:52:55
From: Eric Dumazet <redacted>
Date: Mon, 02 Jan 2012 05:33:31 +0100
[PATCH net-next] sch_sfq: dont put new flow at the end of flows
SFQ enqueue algo puts a new flow _behind_ all pre-existing flows in the
circular list. In fact this is probably an old SFQ implementation bug.
100 Mbits = ~8333 full frames per second, or ~8 frames per ms.
With 50 flows, it means your "new flow" will have to wait 50 packets
being sent before its own packet. Thats the ~6ms.
We certainly can change SFQ to give a priority advantage to new flows,
so that next dequeued packet is taken from a new flow, not an old one.
Reported-by: Dave Taht <redacted>
Signed-off-by: Eric Dumazet <redacted>