From: John A. Sullivan III <hidden> Date: 2011-12-18 05:12:16
Hello, all. I am having some delightful success building a test WAN
environment using hfsc and netem. We have placed netem on both ingress
and egress for various test environment reasons. We are also using hfsc
on both ingress and egress for traffic shaping.
Since netem appears to be classless, we realized we would need to
replace the SFQ on each leaf with netem which we really didn't want to
do - not only to not lose SFQ but because we didn't want to maintain the
netem parameters on each leaf. So, we activated our ifb1 interface,
placed netem on it and redirected all the egress traffic to ifb1. Taht
worked fine.
However, how do we do this on the ingress? To use hfsc on ingres, we are
already redirecting to ifb0. We can't redirect ifb0 to ifb1. If we
apply multiple filters, one to redirect into ifb0 and the other to ifb1,
only the first match takes effect. So we are living with replacing SFQ
on the ifb0 leaves with netem.
Is there any other way? Thanks - John
In case it is of interest, here is the set of rules we are using:
tc qdisc add dev eth1 root handle 1: hfsc default 20
tc class add dev eth1 parent 1: classid 1:1 hfsc sc rate 1490kbit ul rate 1490kbit
tc class add dev eth1 parent 1:1 classid 1:20 hfsc rt rate 400kbit ls rate 200kbit
tc qdisc add dev eth1 parent 1:20 handle 1201 sfq perturb 10
tc class add dev eth1 parent 1:1 classid 1:10 hfsc rt umax 16kbit dmax 50ms rate 200kbit ls rate 1000kbit
tc qdisc add dev eth1 parent 1:10 handle 1101 sfq perturb 60
tc class add dev eth1 parent 1:1 classid 1:30 hfsc rt umax 1514b dmax 20ms rate 20kbit
tc qdisc add dev eth1 parent 1:30 handle 1301 sfq perturb 60
iptables -t mangle -A POSTROUTING -p 6 --syn --dport 443 -j CONNMARK --set-mark 0x10
iptables -t mangle -A PREROUTING -p 6 --syn --dport 822 -j CONNMARK --set-mark 0x11
iptables -t mangle -A POSTROUTING -o eth1 -p 6 -j CONNMARK --restore-mark
tc filter add dev eth1 parent 1:0 protocol ip prio 10 handle 0x10 fw flowid 1:10
tc filter add dev eth1 parent 1:0 protocol ip prio 10 handle 0x11 fw flowid 1:30
tc qdisc add dev eth1 ingress
modprobe ifb
ifconfig ifb0 up
tc filter add dev eth1 parent ffff: protocol ip prio 50 u32 match u32 0 0 action mirred egress redirect dev ifb0
tc qdisc add dev ifb0 root handle 1: hfsc default 20
tc class add dev ifb0 parent 1: classid 1:1 hfsc sc rate 1490kbit ul rate 1490kbit
tc class add dev ifb0 parent 1:1 classid 1:20 hfsc rt rate 400kbit ls rate 200kbit
tc qdisc add dev ifb0 parent 1:20 handle 1201 netem delay 25ms 5ms distribution normal loss 0.1% 30%
tc class add dev ifb0 parent 1:1 classid 1:10 hfsc rt umax 16kbit dmax 50ms rate 200kbit ls rate 1000kbit
tc qdisc add dev ifb0 parent 1:10 handle 1101 netem delay 25ms 5ms distribution normal loss 0.1% 30%
tc class add dev ifb0 parent 1:1 classid 1:30 hfsc rt umax 1514b dmax 20ms rate 20kbit
tc qdisc add dev ifb0 parent 1:30 handle 1301 netem delay 25ms 5ms distribution normal loss 0.1% 30%
tc filter add dev ifb0 parent 1:0 protocol ip prio 1 handle 6: u32 divisor 1
tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 match ip protocol 6 0xff link 6: offset at 0 mask 0x0f00 shift 6 plus 0 eat
tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 ht 6:0 match tcp src 443 0x00ff flowid 1:10
tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 ht 6:0 match tcp dst 822 0xff00 flowid 1:30
ifconfig ifb1 up
tc qdisc add dev ifb1 root handle 2 netem delay 25ms 5ms distribution normal loss 0.1% 30%
tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 match u32 0 0 action mirred egress redirect dev ifb1
From: Stephen Hemminger <hidden> Date: 2011-12-18 19:55:53
On Sun, 18 Dec 2011 00:12:12 -0500
"John A. Sullivan III" [off-list ref] wrote:
Since netem appears to be classless, we realized we would need to
replace the SFQ on each leaf with netem which we really didn't want to
do - not only to not lose SFQ but because we didn't want to maintain the
netem parameters on each leaf. So, we activated our ifb1 interface,
placed netem on it and redirected all the egress traffic to ifb1. Taht
worked fine.
From: John A. Sullivan III <hidden> Date: 2011-12-19 16:53:32
On Sun, 2011-12-18 at 11:55 -0800, Stephen Hemminger wrote:
On Sun, 18 Dec 2011 00:12:12 -0500
"John A. Sullivan III" [off-list ref] wrote:
quoted
Since netem appears to be classless, we realized we would need to
replace the SFQ on each leaf with netem which we really didn't want to
do - not only to not lose SFQ but because we didn't want to maintain the
netem parameters on each leaf. So, we activated our ifb1 interface,
placed netem on it and redirected all the egress traffic to ifb1. Taht
worked fine.
Current versions of netem can take one class.
<snip>
Thanks but how would that work? For example, I assume we could not send
netem processed packets to SFQ because SFQ is classless. We tried
anyway and got:
root@testswitch01:~# tc class add dev ifb0 parent 1201: classid 1202 sfq
perturb 60
Error: Qdisc "sfq" is classless.
root@testswitch01:~# tc qdisc add dev ifb0 parent 1201: handle 1202 sfq
perturb 60
RTNETLINK answers: Operation not supported
1201 is a netem qdisc at the end of hfsc.
Not being quite sure what you meant, we thought we experiment before
asking so we tried to attach an hfsc class to the netem qdisc. We
didn't think it would work and it didn't:
root@testswitch01:~# tc qdisc add dev eth3 root handle 7 netem delay
25ms 5ms distribution normal loss 0.1% 30%
root@testswitch01:~# tc class add dev eth3 parent 7: classid 7:1 hfsc sc
rate 1490kbit ul rate 1490kbit
RTNETLINK answers: Invalid argument
So we tried adding the hfsc qdisc first:
root@testswitch01:~# tc qdisc add dev eth3 parent 7: handle 7:1 hfsc
default 70
RTNETLINK answers: File exists
Then, just for kicks, we tried adding an SFQ qdisc in case the problem
with the previous attempts was that the netem qdisc was not at the top
level:
root@testswitch01:~# tc qdisc add dev eth3 parent 7: handle 7:1 sfq
perturb 60
RTNETLINK answers: File exists
So I'm still not sure how we can do anything other than stick netem on
the end of one of our branches or at root. Thanks - John
From: Eric Dumazet <hidden> Date: 2011-12-23 17:34:04
Le dimanche 18 décembre 2011 à 11:55 -0800, Stephen Hemminger a écrit :
On Sun, 18 Dec 2011 00:12:12 -0500
"John A. Sullivan III" [off-list ref] wrote:
quoted
Since netem appears to be classless, we realized we would need to
replace the SFQ on each leaf with netem which we really didn't want to
do - not only to not lose SFQ but because we didn't want to maintain the
netem parameters on each leaf. So, we activated our ifb1 interface,
placed netem on it and redirected all the egress traffic to ifb1. Taht
worked fine.
Current versions of netem can take one class.
--
Hmm, I can see that (commit 10f6dfcfde884441)
But it wont work very well, it assumes qdisc uses a single queue if
netem reordering is requested :
(__skb_queue_head(&q->qdisc->q, skb))
We should allow reordering if netem queue is changed from tfifo, only if
new qdisc is compatible with __skb_queue_head(&q->qdisc->q, skb)
(maybe providing a new ->queue_at_head() new ops)
From: Eric Dumazet <hidden> Date: 2011-12-23 17:39:14
Le vendredi 23 décembre 2011 à 18:33 +0100, Eric Dumazet a écrit :
Le dimanche 18 décembre 2011 à 11:55 -0800, Stephen Hemminger a écrit :
quoted
On Sun, 18 Dec 2011 00:12:12 -0500
"John A. Sullivan III" [off-list ref] wrote:
quoted
Since netem appears to be classless, we realized we would need to
replace the SFQ on each leaf with netem which we really didn't want to
do - not only to not lose SFQ but because we didn't want to maintain the
netem parameters on each leaf. So, we activated our ifb1 interface,
placed netem on it and redirected all the egress traffic to ifb1. Taht
worked fine.
Current versions of netem can take one class.
--
Hmm, I can see that (commit 10f6dfcfde884441)
But it wont work very well, it assumes qdisc uses a single queue if
netem reordering is requested :
(__skb_queue_head(&q->qdisc->q, skb))
We should allow reordering if netem queue is changed from tfifo, only if
new qdisc is compatible with __skb_queue_head(&q->qdisc->q, skb)
(maybe providing a new ->queue_at_head() new ops)
Also, child qdisc must not scratch skb->cb[], since netem stores
time_to_send in it.
I guess nobody actually tried this netem mis-feature :(
I'll send a fix.
From: Dave Taht <hidden> Date: 2011-12-23 17:54:02
On Fri, Dec 23, 2011 at 6:39 PM, Eric Dumazet [off-list ref] wrote:
Le vendredi 23 décembre 2011 à 18:33 +0100, Eric Dumazet a écrit :
quoted
Le dimanche 18 décembre 2011 à 11:55 -0800, Stephen Hemminger a écrit :
quoted
On Sun, 18 Dec 2011 00:12:12 -0500
"John A. Sullivan III" [off-list ref] wrote:
quoted
Since netem appears to be classless, we realized we would need to
replace the SFQ on each leaf with netem which we really didn't want to
do - not only to not lose SFQ but because we didn't want to maintain the
netem parameters on each leaf. So, we activated our ifb1 interface,
placed netem on it and redirected all the egress traffic to ifb1. Taht
worked fine.
Current versions of netem can take one class.
--
Hmm, I can see that (commit 10f6dfcfde884441)
But it wont work very well, it assumes qdisc uses a single queue if
netem reordering is requested :
(__skb_queue_head(&q->qdisc->q, skb))
We should allow reordering if netem queue is changed from tfifo, only if
new qdisc is compatible with __skb_queue_head(&q->qdisc->q, skb)
(maybe providing a new ->queue_at_head() new ops)
Also, child qdisc must not scratch skb->cb[], since netem stores
time_to_send in it.
Are there any place where all 48 bytes of cb are used?
I wouldn't mind if 'time_to_send' became a separate skb field
for a more generic 'time_in_queue'...
I guess nobody actually tried this netem mis-feature :(
I'll send a fix.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Eric Dumazet <hidden> Date: 2011-12-23 18:28:31
Le vendredi 23 décembre 2011 à 18:54 +0100, Dave Taht a écrit :
Are there any place where all 48 bytes of cb are used?
Yes, but on in qdisc layer.
struct tcp_skb_cb is known to be 44 bytes (when IPv6 is enabled)
In qdisc layer, we use a small part of it, for the moment.
I wouldn't mind if 'time_to_send' became a separate skb field
for a more generic 'time_in_queue'...
This wont happen.
As I posted in an earlier patch, this can be added in "struct
qdisc_skb_cb"
From: Dave Taht <hidden> Date: 2011-12-23 18:54:09
On Fri, Dec 23, 2011 at 7:28 PM, Eric Dumazet [off-list ref] wrote:
Le vendredi 23 décembre 2011 à 18:54 +0100, Dave Taht a écrit :
quoted
Are there any place where all 48 bytes of cb are used?
Yes, but on in qdisc layer.
struct tcp_skb_cb is known to be 44 bytes (when IPv6 is enabled)
In qdisc layer, we use a small part of it, for the moment.
quoted
I wouldn't mind if 'time_to_send' became a separate skb field
for a more generic 'time_in_queue'...
This wont happen.
As I posted in an earlier patch, this can be added in "struct
qdisc_skb_cb"
Ah... this patch?
http://patchwork.ozlabs.org/patch/125329/
I liked what I saw then, but nobody chirped up to review it...
I guess I know what I'm doing this weekend.
From: Stephen Hemminger <hidden> Date: 2011-12-23 19:07:52
On Fri, 23 Dec 2011 19:28:27 +0100
Eric Dumazet [off-list ref] wrote:
Le vendredi 23 décembre 2011 à 18:54 +0100, Dave Taht a écrit :
quoted
Are there any place where all 48 bytes of cb are used?
Yes, but on in qdisc layer.
struct tcp_skb_cb is known to be 44 bytes (when IPv6 is enabled)
In qdisc layer, we use a small part of it, for the moment.
quoted
I wouldn't mind if 'time_to_send' became a separate skb field
for a more generic 'time_in_queue'...
This wont happen.
As I posted in an earlier patch, this can be added in "struct
qdisc_skb_cb"
skb_cb is the dumping ground of the networking layer.
The assumption was that the qdisc could use the skb_cb
for it's own scratchpad. Netem is using it for tagging
packets in the queue.
So basically, netem, choke, and sfb are incompatible with
each other. This is not that bad, why not add a flag to qdisc
ops to indicate which qdisc are using cb and block user from
trying to do something bogus.
From: Eric Dumazet <hidden> Date: 2011-12-23 19:21:27
Le vendredi 23 décembre 2011 à 11:07 -0800, Stephen Hemminger a écrit :
skb_cb is the dumping ground of the networking layer.
The assumption was that the qdisc could use the skb_cb
for it's own scratchpad. Netem is using it for tagging
packets in the queue.
So basically, netem, choke, and sfb are incompatible with
each other. This is not that bad, why not add a flag to qdisc
ops to indicate which qdisc are using cb and block user from
trying to do something bogus.
This is not how I planned to solve the problem.
I think we need an internal tfifo for netem use.
Then be able to add another qdisc on top of netem.
tfifo as a first stage, hardcoded (only limit is tunable)
[ optional 2nd stage, any qdisc ]
netem_queue()
{
queue packet to tfifo
(eventually at head, of reordering)
}
netem_dequeue()
{
if (other_qdisc) {
for_each_packet_from_tfifo_time_ready() {
other_qdisc->enqueue(skb);
}
try_to_dequeue_one_packet_from(other_qdisc);
} else {
dequeue_one_packet_from_tfifo_time_ready();
}
}
From: David Miller <davem@davemloft.net> Date: 2011-12-23 19:36:58
From: Stephen Hemminger <redacted>
Date: Fri, 23 Dec 2011 11:07:49 -0800
So basically, netem, choke, and sfb are incompatible with
each other. This is not that bad, why not add a flag to qdisc
ops to indicate which qdisc are using cb and block user from
trying to do something bogus.
Or we could do what we do in the inet stack, define a layout
that allows the different layers to use different parts of the
CB.
@@ -67,7 +67,11 @@*/structnetem_sched_data{+/* internal t(ime)fifo qdisc uses sch->q and sch->limit */++/* optional qdisc for classful handling (NULL at netem init) */structQdisc*qdisc;+structqdisc_watchdogwatchdog;psched_tdiff_tlatency;
@@ -117,7 +121,9 @@ struct netem_sched_data {};-/* Time stamp put into socket buffer control block */+/* Time stamp put into socket buffer control block+*Onlyvalidwhenskbsareinourinternalt(ime)fifoqueue.+*/structnetem_skb_cb{psched_time_ttime_to_send;};
@@ -324,6 +330,31 @@ static psched_time_t packet_len_2_sched_time(unsigned int len, struct netem_schereturnPSCHED_NS2TICKS(ticks);}+staticinttfifo_enqueue(structsk_buff*nskb,structQdisc*sch)+{+structsk_buff_head*list=&sch->q;+psched_time_ttnext=netem_skb_cb(nskb)->time_to_send;+structsk_buff*skb;++if(likely(skb_queue_len(list)<sch->limit)){+skb=skb_peek_tail(list);+/* Optimize for add at tail */+if(likely(!skb||tnext>=netem_skb_cb(skb)->time_to_send))+returnqdisc_enqueue_tail(nskb,sch);++skb_queue_reverse_walk(list,skb){+if(tnext>=netem_skb_cb(skb)->time_to_send)+break;+}++__skb_queue_after(list,skb,nskb);+sch->qstats.backlog+=qdisc_pkt_len(nskb);+returnNET_XMIT_SUCCESS;+}++returnqdisc_reshape_fail(nskb,sch);+}+/**Insertoneskbintoqdisc.*Note:parentdependsonreturnvaluetoaccountforqueuelength.
@@ -951,7 +910,7 @@ static int netem_dump_class(struct Qdisc *sch, unsigned long cl,{structnetem_sched_data*q=qdisc_priv(sch);-if(cl!=1)/* only one class */+if(cl!=1||!q->qdisc)/* only one class */return-ENOENT;tcm->tcm_handle|=TC_H_MIN(1);
@@ -965,14 +924,13 @@ static int netem_graft(struct Qdisc *sch, unsigned long arg, struct Qdisc *new,{structnetem_sched_data*q=qdisc_priv(sch);-if(new==NULL)-new=&noop_qdisc;-sch_tree_lock(sch);*old=q->qdisc;q->qdisc=new;-qdisc_tree_decrease_qlen(*old,(*old)->q.qlen);-qdisc_reset(*old);+if(*old){+qdisc_tree_decrease_qlen(*old,(*old)->q.qlen);+qdisc_reset(*old);+}sch_tree_unlock(sch);return0;
From: Stephen Hemminger <hidden> Date: 2011-12-29 06:17:36
On Thu, 29 Dec 2011 05:26:00 +0100
Eric Dumazet [off-list ref] wrote:
Commit 10f6dfcfde (Revert "sch_netem: Remove classful functionality")
reintroduced classful functionality to netem, but broke basic netem
behavior :
netem uses an t(ime)fifo queue, and store timestamps in skb->cb[]
If qdisc is changed, time constraints are not respected and other qdisc
can destroy skb->cb[] and block netem at dequeue time.
Fix this by always using internal tfifo, and optionally attach a child
qdisc to netem.
Example of use :
DEV=eth3
tc qdisc del dev $DEV root
tc qdisc add dev $DEV root handle 30: est 1sec 8sec netem delay 20ms 10ms
tc qdisc add dev $DEV parent 30:0 sfq
Does it work with TBF which is a more useful option?
Also, the whole tfifo idea is only to support the wierd idea that
if doing random delay that packets should get reordered based on the
results of the random value; it was an behavior some users wanted
because that is what NISTnet did.
From: Eric Dumazet <hidden> Date: 2011-12-29 09:12:08
Le mercredi 28 décembre 2011 à 22:17 -0800, Stephen Hemminger a écrit :
On Thu, 29 Dec 2011 05:26:00 +0100
Eric Dumazet [off-list ref] wrote:
quoted
Commit 10f6dfcfde (Revert "sch_netem: Remove classful functionality")
reintroduced classful functionality to netem, but broke basic netem
behavior :
netem uses an t(ime)fifo queue, and store timestamps in skb->cb[]
If qdisc is changed, time constraints are not respected and other qdisc
can destroy skb->cb[] and block netem at dequeue time.
Fix this by always using internal tfifo, and optionally attach a child
qdisc to netem.
Example of use :
DEV=eth3
tc qdisc del dev $DEV root
tc qdisc add dev $DEV root handle 30: est 1sec 8sec netem delay 20ms 10ms
tc qdisc add dev $DEV parent 30:0 sfq
Does it work with TBF which is a more useful option?
Also, the whole tfifo idea is only to support the wierd idea that
if doing random delay that packets should get reordered based on the
results of the random value; it was an behavior some users wanted
because that is what NISTnet did.
tfifo supports a time ordered queuing, wich mimics some jitter in the
network. This seems quite useful.
I see what you suggest : adding 'time_to_send' in the generic qdisc cb.
But it makes no sense if we attach a reordering qdisc, like SFQ :
A 'high prio' packet will block the whole netem because we'll have to
throttle since this packet time_to_send will be in the future, while
many other elligible packets are in queue.
In the case no jitter is asked to netem, we directly enqueue at the
queue tail with no extra cost, since we need to access last skb in queue
to perform the qdisc_enqueue_tail()
I am sending a v2 because of two lines I inadvertently removed in the case
we queue the new packet at the head of tfifo. (allowing to bypass the
sch->limit check... I'll send a separate patch to add this check)
Thanks
[PATCH v2 net-next] netem: fix classful handling
Commit 10f6dfcfde (Revert "sch_netem: Remove classful functionality")
reintroduced classful functionality to netem, but broke basic netem
behavior :
netem uses an t(ime)fifo queue, and store timestamps in skb->cb[]
If qdisc is changed, time constraints are not respected and other qdisc
can destroy skb->cb[] and block netem at dequeue time.
Fix this by always using internal tfifo, and optionally attach a child
qdisc to netem (or a tree of qdiscs)
Example of use :
DEV=eth3
tc qdisc del dev $DEV root
tc qdisc add dev $DEV root handle 30: est 1sec 8sec netem delay 20ms 10ms
tc qdisc add dev $DEV handle 40:0 parent 30:0 tbf \
burst 20480 limit 20480 mtu 1514 rate 32000bps
qdisc netem 30: root refcnt 18 limit 1000 delay 20.0ms 10.0ms
Sent 190792 bytes 413 pkt (dropped 0, overlimits 0 requeues 0)
rate 18416bit 3pps backlog 0b 0p requeues 0
qdisc tbf 40: parent 30: rate 256000bit burst 20Kb/8 mpu 0b lat 0us
Sent 190792 bytes 413 pkt (dropped 6, overlimits 10 requeues 0)
backlog 0b 5p requeues 0
Signed-off-by: Eric Dumazet <redacted>
CC: Stephen Hemminger <redacted>
---
net/sched/sch_netem.c | 202 ++++++++++++++++------------------------
1 file changed, 81 insertions(+), 121 deletions(-)
@@ -67,7 +67,11 @@*/structnetem_sched_data{+/* internal t(ime)fifo qdisc uses sch->q and sch->limit */++/* optional qdisc for classful handling (NULL at netem init) */structQdisc*qdisc;+structqdisc_watchdogwatchdog;psched_tdiff_tlatency;
@@ -117,7 +121,9 @@ struct netem_sched_data {};-/* Time stamp put into socket buffer control block */+/* Time stamp put into socket buffer control block+*Onlyvalidwhenskbsareinourinternalt(ime)fifoqueue.+*/structnetem_skb_cb{psched_time_ttime_to_send;};
@@ -324,6 +330,31 @@ static psched_time_t packet_len_2_sched_time(unsigned int len, struct netem_schereturnPSCHED_NS2TICKS(ticks);}+staticinttfifo_enqueue(structsk_buff*nskb,structQdisc*sch)+{+structsk_buff_head*list=&sch->q;+psched_time_ttnext=netem_skb_cb(nskb)->time_to_send;+structsk_buff*skb;++if(likely(skb_queue_len(list)<sch->limit)){+skb=skb_peek_tail(list);+/* Optimize for add at tail */+if(likely(!skb||tnext>=netem_skb_cb(skb)->time_to_send))+returnqdisc_enqueue_tail(nskb,sch);++skb_queue_reverse_walk(list,skb){+if(tnext>=netem_skb_cb(skb)->time_to_send)+break;+}++__skb_queue_after(list,skb,nskb);+sch->qstats.backlog+=qdisc_pkt_len(nskb);+returnNET_XMIT_SUCCESS;+}++returnqdisc_reshape_fail(nskb,sch);+}+/**Insertoneskbintoqdisc.*Note:parentdependsonreturnvaluetoaccountforqueuelength.
@@ -951,7 +912,7 @@ static int netem_dump_class(struct Qdisc *sch, unsigned long cl,{structnetem_sched_data*q=qdisc_priv(sch);-if(cl!=1)/* only one class */+if(cl!=1||!q->qdisc)/* only one class */return-ENOENT;tcm->tcm_handle|=TC_H_MIN(1);
@@ -965,14 +926,13 @@ static int netem_graft(struct Qdisc *sch, unsigned long arg, struct Qdisc *new,{structnetem_sched_data*q=qdisc_priv(sch);-if(new==NULL)-new=&noop_qdisc;-sch_tree_lock(sch);*old=q->qdisc;q->qdisc=new;-qdisc_tree_decrease_qlen(*old,(*old)->q.qlen);-qdisc_reset(*old);+if(*old){+qdisc_tree_decrease_qlen(*old,(*old)->q.qlen);+qdisc_reset(*old);+}sch_tree_unlock(sch);return0;
From: Hagen Paul Pfeifer <hidden> Date: 2011-12-29 16:52:52
* Eric Dumazet | 2011-12-29 10:12:02 [+0100]:
quoted
Also, the whole tfifo idea is only to support the wierd idea that
if doing random delay that packets should get reordered based on the
results of the random value; it was an behavior some users wanted
because that is what NISTnet did.
tfifo supports a time ordered queuing, wich mimics some jitter in the
network. This seems quite useful.
I see what you suggest : adding 'time_to_send' in the generic qdisc cb.
But it makes no sense if we attach a reordering qdisc, like SFQ :
A 'high prio' packet will block the whole netem because we'll have to
throttle since this packet time_to_send will be in the future, while
many other elligible packets are in queue.
In other words netem jitter and a qdisc !tfifo will not work. Correct? The
rate extension also peak the last packet to get the reference time (assuming a
strict ordering):
[...]
now = netem_skb_cb(skb_peek_tail(list))->time_to_send;
[...]
We should avoid a different (unseeable) behavior depending on the queue
(tfifo, SFQ). Another point: operate netem and qdisc on the same computer can
lead to timing abnormalities. In our test setups we operate qdisc/tcp/whatever
setups and netem on more then on computer.
Hagen
From: Eric Dumazet <hidden> Date: 2011-12-29 17:15:55
Le jeudi 29 décembre 2011 à 17:52 +0100, Hagen Paul Pfeifer a écrit :
* Eric Dumazet | 2011-12-29 10:12:02 [+0100]:
quoted
quoted
Also, the whole tfifo idea is only to support the wierd idea that
if doing random delay that packets should get reordered based on the
results of the random value; it was an behavior some users wanted
because that is what NISTnet did.
tfifo supports a time ordered queuing, wich mimics some jitter in the
network. This seems quite useful.
I see what you suggest : adding 'time_to_send' in the generic qdisc cb.
But it makes no sense if we attach a reordering qdisc, like SFQ :
A 'high prio' packet will block the whole netem because we'll have to
throttle since this packet time_to_send will be in the future, while
many other elligible packets are in queue.
In other words netem jitter and a qdisc !tfifo will not work. Correct? The
rate extension also peak the last packet to get the reference time (assuming a
strict ordering):
Yep, current situation is borked. It assumes we _use_ tfifo, for delay
jitters but also for rate extension.
[...]
now = netem_skb_cb(skb_peek_tail(list))->time_to_send;
[...]
We should avoid a different (unseeable) behavior depending on the queue
(tfifo, SFQ). Another point: operate netem and qdisc on the same computer can
lead to timing abnormalities. In our test setups we operate qdisc/tcp/whatever
setups and netem on more then on computer.
After my patch you could use netem as a delay module before a complex
qdisc setup for example.
[ Simulating a 10ms delay on a 10Gigabit link is expensive, since you
need to allow up to ~150.000 packets in tfifo. Maybe we should switch to
tbfifo [giving a limit in bytes, not packets ] ]
From: Hagen Paul Pfeifer <hidden> Date: 2011-12-29 17:43:26
* Eric Dumazet | 2011-12-29 18:15:50 [+0100]:
quoted
In other words netem jitter and a qdisc !tfifo will not work. Correct? The
rate extension also peak the last packet to get the reference time (assuming a
strict ordering):
Yep, current situation is borked. It assumes we _use_ tfifo, for delay
jitters but also for rate extension.
Mhh, should we signal this to the user via 'tc -s qdisc show'? Or should we
assume that a user who set netem rate|jitter AND a qdisc !tfifo knows what he
does - because we assume he is a experienced user? At least somewhere in the
manpage a comment should point to this characteristic.
From: Eric Dumazet <hidden> Date: 2011-12-29 18:10:44
Le jeudi 29 décembre 2011 à 18:43 +0100, Hagen Paul Pfeifer a écrit :
* Eric Dumazet | 2011-12-29 18:15:50 [+0100]:
quoted
quoted
In other words netem jitter and a qdisc !tfifo will not work. Correct? The
rate extension also peak the last packet to get the reference time (assuming a
strict ordering):
Yep, current situation is borked. It assumes we _use_ tfifo, for delay
jitters but also for rate extension.
Mhh, should we signal this to the user via 'tc -s qdisc show'? Or should we
assume that a user who set netem rate|jitter AND a qdisc !tfifo knows what he
does - because we assume he is a experienced user? At least somewhere in the
manpage a comment should point to this characteristic.
I dont quite understand the question. The patch I posted is supposed to
fix the problem. What do you want to tell to the user ?
netem module is probably only used by experimented users, on very recent
kernels anyway.
From: Hagen Paul Pfeifer <hidden> Date: 2011-12-29 18:25:05
* Eric Dumazet | 2011-12-29 19:10:36 [+0100]:
I dont quite understand the question. The patch I posted is supposed to
fix the problem. What do you want to tell to the user ?
I assumed that the patch makes it possible to replace standard tfifo?! Tfifo
provides strict ordering, other qdisc's do not. So I thought if someone use
netem rate|jitter with e.g. SFQ then this should be mentioned somewhere. E.g.
"rate|jitter can only be used with tfifo qdisc". Correct me if I am wrong.
Cheers
From: Stephen Hemminger <hidden> Date: 2011-12-29 18:31:53
On Thu, 29 Dec 2011 19:25:03 +0100
Hagen Paul Pfeifer [off-list ref] wrote:
* Eric Dumazet | 2011-12-29 19:10:36 [+0100]:
quoted
I dont quite understand the question. The patch I posted is supposed to
fix the problem. What do you want to tell to the user ?
I assumed that the patch makes it possible to replace standard tfifo?! Tfifo
provides strict ordering, other qdisc's do not. So I thought if someone use
netem rate|jitter with e.g. SFQ then this should be mentioned somewhere. E.g.
"rate|jitter can only be used with tfifo qdisc". Correct me if I am wrong.
Cheers
This is actually a feature. It is documented that tfifo can be replaced
with pfifo. In other words, if default (tfifo) is used then packets
can be reordered by the delay/jitter values. But if pfifo (or other
qdisc) is used, the packets will not be reordered.
From: Eric Dumazet <hidden> Date: 2011-12-29 18:36:28
Le jeudi 29 décembre 2011 à 19:25 +0100, Hagen Paul Pfeifer a écrit :
* Eric Dumazet | 2011-12-29 19:10:36 [+0100]:
quoted
I dont quite understand the question. The patch I posted is supposed to
fix the problem. What do you want to tell to the user ?
I assumed that the patch makes it possible to replace standard tfifo?! Tfifo
provides strict ordering, other qdisc's do not. So I thought if someone use
netem rate|jitter with e.g. SFQ then this should be mentioned somewhere. E.g.
"rate|jitter can only be used with tfifo qdisc". Correct me if I am wrong.
Current netem uses a single queue, default tfifo.
Then if you change this tfifo by SFQ, you lose tfifo, and netem doesnt
work at all.
I claim we cannot remove tfifo.
After my patch, you now have :
1) An internal mandatory tfifo queue, to fulfill time_to_send
requirements.
2) An optional qdisc (SFQ in your example), where packets are queued
once dequeued from tfifo at the right time (after netem delay/rate
respected), eventually a packet can finaly be delivered to device with a
_bigger_ delay than the one predicted in tfifo, because of trafic
shaping happening in this optional qdisc.
Full netem block :
+---------+ +--------+
-->>-enqueue--| tfifo |---->>>>--enqueue--| SFQ |-dequeue--->>>>>
+---------+ +--------+