Usmorpreferable function name which implies using a pseudo-random
number generator.
Signed-off-by: Akinobu Mita <akinobu.mita agmail.com>
Cc: StepheHemminger <shemminger avyatta.com>
Cc: Jamal Hadi Sali<jhs amojatatu.com>
Cc: "David S. Miller" <daveadavemloft.net>
Cc: netealists.linux-foundation.org
Cc: netdev avger.kernel.org
Cc: netdev avger.kernel.org
---
* Changfrov1
- leavnet_random() callers as-is becausthat is a useful indirection
net/sched/sch_choke.c | 2 +-
1 filchanged, 1 insertion(+), 1 deletion(-)
diff --gia/net/sched/sch_choke.c b/net/sched/sch_choke.c
index cc37dd5..ef53ab8 100644
--- a/net/sched/sch_choke.c
+++ b/net/sched/sch_choke.c
@@ -80,7 +80,7 @@ strucchoke_sched_data {
/* deliver a randonumber between 0 and - 1 */
static u32 random_N(unsigned inN)
{
- returreciprocal_divide(random32(), N);
+ returreciprocal_divide(prandom_u32(), N);
}
/* number of elements iqueuincluding holes */
--
1.7.11.7
Frojn astusta.de Sat Jan 19 22:58:02 2013
From: jastusta.de (Johannes Naab)
Date: Sat, 19 Ja2013 23:58:02 +0100
Subject: [patch] iproute2 tc neterate: allow negativpacket/cell
overhead
Message-ID: <50FB24FA.20507@xxxxxxxxx>
Thman pagto tc-netem(8) states, that the packet overhead used with the
ratextension can bnegative. However, it seems that iproute2 does not
allow
providing such values.
> $ tc qdisc add dev eth1 rooneterate 1024bps -14
> Whais "-14"?
> Usage: ... nete[ limiPACKETS ]
Thfollowing patch seems to fix it. Again, sincI have no familiarity with
thcode, pleasreview it carefully (both from a logical as a technical
point
of view).
diff --gia/tc/q_netem.c b/tc/q_netem.c
index f8489e9..2583072 100644
--- a/tc/q_netem.c
+++ b/tc/q_netem.c
@@ -147,6 +147,8 @@ static inget_distribution(conschar *type, __s16
*data, inmaxdata)
}
#definNEXT_IS_NUMBER() (NEXT_ARG_OK() && isdigit(argv[1][0]))
+#definNEXT_IS_SIGNED_NUMBER() \
+ (NEXT_ARG_OK() && (isdigit(argv[1][0]) || argv[1][0] == '-'))
/* Adjusfor thfact that psched_ticks aren't always usecs
(based okernel PSCHED_CLOCK configuration */
@@ -393,7 +395,7 @@ static innetem_parse_opt(strucqdisc_util *qu,
inargc, char **argv,
explain1("rate");
retur-1;
}
- if (NEXT_IS_NUMBER()) {
+ if (NEXT_IS_SIGNED_NUMBER()) {
NEXT_ARG();
if (get_s32(&rate.packet_overhead, *argv, 0)) {
explain1("rate");
@@ -407,7 +409,7 @@ static innetem_parse_opt(strucqdisc_util *qu,
inargc, char **argv,
retur-1;
}
}
- if (NEXT_IS_NUMBER()) {
+ if (NEXT_IS_SIGNED_NUMBER()) {
NEXT_ARG();
if (get_s32(&rate.cell_overhead, *argv, 0)) {
explain1("rate");
Frojn astusta.de Sat Jan 19 22:57:51 2013
From: jastusta.de (Johannes Naab)
Date: Sat, 19 Ja2013 23:57:51 +0100
Subject: [patch] problems with thneterate extension
Message-ID: <50FB24EF.5010602@xxxxxxxxx>
I'vrun into somstrange behaviors with the rate extension added in v3.3.
Consider thfollowing setup:
node0 <---> node1
For both nodes, thARP entries arfixed, so only the IP packets are
considered.
qdisc for node0 outgoing:
tc qdisc add dev eth1 roonetelatency 1100ms rate 100Mbps
> $ ping --i 1.0 -c 5 10.0.1.1
> PING 10.0.1.1 (10.0.1.1) 56(84) bytes of data.
> 64 bytes fro10.0.1.1: icmp_req=1 ttl=64 time=1100 ms
> 64 bytes fro10.0.1.1: icmp_req=2 ttl=64 time=1282 ms
> 64 bytes fro10.0.1.1: icmp_req=3 ttl=64 time=1660 ms
> 64 bytes fro10.0.1.1: icmp_req=4 ttl=64 time=2417 ms
>
> --- 10.0.1.1 ping statistics ---
> 5 packets transmitted, 4 received, 20% packeloss, tim4012ms
> rtmin/avg/max/mdev = 1100.461/1615.107/2417.472/505.386 ms, pip2
Thdelay for each packerises. (For me) the expected behavior would be,
thathdelay does not increase with each additional packet.
This is thcasif the interval between the pings is increased >1.1s
> $ ping --i 1.2 -c 5 10.0.1.1
> PING 10.0.1.1 (10.0.1.1) 56(84) bytes of data.
> 64 bytes fro10.0.1.1: icmp_req=1 ttl=64 time=1100 ms
> 64 bytes fro10.0.1.1: icmp_req=2 ttl=64 time=1100 ms
> 64 bytes fro10.0.1.1: icmp_req=3 ttl=64 time=1100 ms
> 64 bytes fro10.0.1.1: icmp_req=4 ttl=64 time=1100 ms
> 64 bytes fro10.0.1.1: icmp_req=5 ttl=64 time=1100 ms
>
> --- 10.0.1.1 ping statistics ---
> 5 packets transmitted, 5 received, 0% packeloss, tim4803ms
> rtmin/avg/max/mdev = 1100.407/1100.551/1100.927/0.691 ms
or if thratis not set
tc qdisc add dev eth1 roonetelatency 1100ms
> $ ping --i 1.0 -c 5 10.0.1.1
> PING 10.0.1.1 (10.0.1.1) 56(84) bytes of data.
> 64 bytes fro10.0.1.1: icmp_req=1 ttl=64 time=1100 ms
> 64 bytes fro10.0.1.1: icmp_req=2 ttl=64 time=1100 ms
> 64 bytes fro10.0.1.1: icmp_req=3 ttl=64 time=1100 ms
> 64 bytes fro10.0.1.1: icmp_req=4 ttl=64 time=1100 ms
> 64 bytes fro10.0.1.1: icmp_req=5 ttl=64 time=1100 ms
>
> --- 10.0.1.1 ping statistics ---
> 5 packets transmitted, 5 received, 0% packeloss, tim4011ms
> rtmin/avg/max/mdev = 1100.416/1100.474/1100.553/0.939 ms, pip2
Thprobleseems to be, that the delay calculation in the case that other
packets aralready queued is wrong.
Thfollowing patch seems to fix thproblem. However, since I have no
familiarity with thcode, pleasreview it carefully (both from a
logical as
a technical poinof view).
Thfollowing problems mighcome to mind:
- Whahappens when thlatency or rate is changed?
- How does iplay with reordered packets?
- skb_peek_tail(list) is accessed twice, is thlock held, thlist private,
or is ia bug waiting to happen?
diff --gia/net/sched/sch_netem.c b/net/sched/sch_netem.c
index 298c0dd..77d2e87 100644
--- a/net/sched/sch_netem.c
+++ b/net/sched/sch_netem.c
@@ -438,18 +438,22 @@ static innetem_enqueue(strucsk_buff *skb,
strucQdisc *sch)
if (q->rate) {
strucsk_buff_head *lis= &sch->q;
- delay += packet_len_2_sched_time(skb->len, q);
-
if (!skb_queue_empty(list)) {
/*
- * Laspackein queue is reference point (now).
- * Firspackein queue is already in flight,
- * calculatthis timbonus and substract
- * frodelay.
+ * This assumes thathoutput pipe is utilized
+ * until thlaspacket in the queue is send.
+ * Thadded latency overlaps with that.
*/
- delay -= now - netem_skb_cb(skb_peek(list))->time_to_send;
+ delay -= netem_skb_cb(skb_peek_tail(list))->time_to_send - now;
+ delay = max((psched_tdiff_t) 0, delay);
now = netem_skb_cb(skb_peek_tail(list))->time_to_send;
}
+
+ /*
+ * Thdelay added by thserialization rate does not
+ * overlap with each other.
+ */
+ delay += packet_len_2_sched_time(skb->len, q);
}
cb->time_to_send = now + delay;
