* build failure on ixgbe
From: Or Gerlitz @ 2011-11-06 8:32 UTC (permalink / raw)
To: Greg Rose, Alexander Duyck; +Cc: netdev
commit 9487dc844054e1fc691fb82f4e19da337e2ca35e "ixgbe: Fix compiler
warnings" wrapped
the definitions of the below two function with ifdef CONFIG_PCI_IOV but
not all their
usages, once that commit is removed, I can build the code okay
Or.
> linux-2.6.ko.git]# make
> CHK include/linux/version.h
> CHK include/generated/utsrelease.h
> CALL scripts/checksyscalls.sh
> CHK include/generated/compile.h
> CC [M] drivers/net/ethernet/intel/ixgbe/ixgbe_main.o
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c: In function
> ixgbe_set_interrupt_capability:
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:4724: error: implicit
> declaration of function ixgbe_disable_sriov
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c: In function ixgbe_remove:
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:7773: error: implicit
> declaration of function ixgbe_check_vf_assignment
> make[5]: *** [drivers/net/ethernet/intel/ixgbe/ixgbe_main.o] Error 1
> make[4]: *** [drivers/net/ethernet/intel/ixgbe] Error 2
> make[3]: *** [drivers/net/ethernet/intel] Error 2
> make[2]: *** [drivers/net/ethernet] Error 2
> make[1]: *** [drivers/net] Error 2
> make: *** [drivers] Error 2
^ permalink raw reply
* -C O N G R A T U L A T I O N S-
From: CARLSBEG MALAYSIA @ 2011-11-06 12:37 UTC (permalink / raw)
To: netdev
-CARLSBERG MALAYSIA 2011 AWARD-
-YOUR EMAIL HAS BEEN SELECTED & HAVE BEEN AWARDED $650,000.00 USD BY CARLSBERG MALAYSIA-
To Claim Your Prize, Immediately Contact:
Name: MR.FADIL BIN HASSAN
Email: mcarlsberg@kimo.com
Phone: :+60164671274
^ permalink raw reply
* [PATCH 0/5] use kstrtoul, etc
From: Julia Lawall @ 2011-11-06 13:26 UTC (permalink / raw)
To: David S. Miller; +Cc: kernel-janitors, netdev, linux-kernel
These patches replace calls to strict_strtoul, etc by the corresponding
calls to kstrtoul. The complete semantic patch that makes these changes is
as follows. This semantic patch checks that the types are as expected,
which was always the case for these files.
// <smpl>
@@
expression a,b;
{int,long} *c;
@@
-strict_strtol
+kstrtol
(a,b,c)
@@
expression a,b;
long long *c;
@@
-strict_strtoll
+kstrtoll
(a,b,c)
@@
typedef ulong;
expression a,b;
{ulong,unsigned long,unsigned int,size_t} *c;
@@
-strict_strtoul
+kstrtoul
(a,b,c)
@@
expression a,b;
unsigned long long *c;
@@
-strict_strtoull
+kstrtoull
(a,b,c)
@@
expression a,b;
u64 *c;
@@
-strict_strtoull
+kstrtou64
(a,b,c)
@@
@@
(
+BAD(
strict_strtoull(...)
+)
|
+BAD(
strict_strtoul(...)
+)
|
+BAD(
strict_strtol(...)
+)
|
+BAD(
strict_strtoll(...)
+)
)
// </smpl>
^ permalink raw reply
* [PATCH 1/5] net/batman-adv: use kstrtoul, etc
From: Julia Lawall @ 2011-11-06 13:26 UTC (permalink / raw)
To: Marek Lindner
Cc: kernel-janitors, Simon Wunderlich, David S. Miller, b.a.t.m.a.n,
netdev, linux-kernel
In-Reply-To: <1320586010-21931-1-git-send-email-julia@diku.dk>
From: Julia Lawall <julia@diku.dk>
Use kstrtoul, etc instead of the now deprecated strict_strtoul, etc.
A semantic patch rule for the kstrtoul case is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression a,b;
{int,long} *c;
@@
-strict_strtoul
+kstrtoul
(a,b,c)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
net/batman-adv/bat_sysfs.c | 4 ++--
net/batman-adv/gateway_common.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff -u -p a/net/batman-adv/bat_sysfs.c b/net/batman-adv/bat_sysfs.c
--- a/net/batman-adv/bat_sysfs.c
+++ b/net/batman-adv/bat_sysfs.c
@@ -174,7 +174,7 @@ static int store_uint_attr(const char *b
unsigned long uint_val;
int ret;
- ret = strict_strtoul(buff, 10, &uint_val);
+ ret = kstrtoul(buff, 10, &uint_val);
if (ret) {
bat_info(net_dev,
"%s: Invalid parameter received: %s\n",
@@ -239,7 +239,7 @@ static ssize_t store_vis_mode(struct kob
unsigned long val;
int ret, vis_mode_tmp = -1;
- ret = strict_strtoul(buff, 10, &val);
+ ret = kstrtoul(buff, 10, &val);
if (((count == 2) && (!ret) && (val == VIS_TYPE_CLIENT_UPDATE)) ||
(strncmp(buff, "client", 6) == 0) ||
diff -u -p a/net/batman-adv/gateway_common.c b/net/batman-adv/gateway_common.c
--- a/net/batman-adv/gateway_common.c
+++ b/net/batman-adv/gateway_common.c
@@ -97,7 +97,7 @@ static bool parse_gw_bandwidth(struct ne
*tmp_ptr = '\0';
}
- ret = strict_strtol(buff, 10, &ldown);
+ ret = kstrtol(buff, 10, &ldown);
if (ret) {
bat_err(net_dev,
"Download speed of gateway mode invalid: %s\n",
@@ -122,7 +122,7 @@ static bool parse_gw_bandwidth(struct ne
*tmp_ptr = '\0';
}
- ret = strict_strtol(slash_ptr + 1, 10, &lup);
+ ret = kstrtol(slash_ptr + 1, 10, &lup);
if (ret) {
bat_err(net_dev,
"Upload speed of gateway mode invalid: "
^ permalink raw reply
* [PATCH 2/5] net/sunrpc: use kstrtoul, etc
From: Julia Lawall @ 2011-11-06 13:26 UTC (permalink / raw)
To: J. Bruce Fields
Cc: kernel-janitors, Neil Brown, Trond Myklebust, David S. Miller,
linux-nfs, netdev, linux-kernel
In-Reply-To: <1320586010-21931-1-git-send-email-julia@diku.dk>
From: Julia Lawall <julia@diku.dk>
Use kstrtoul, etc instead of the now deprecated strict_strtoul, etc.
A semantic patch rule for the kstrtoul case is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression a,b;
{int,long} *c;
@@
-strict_strtoul
+kstrtoul
(a,b,c)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
net/sunrpc/addr.c | 6 +++---
net/sunrpc/auth.c | 2 +-
net/sunrpc/xprtsock.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff -u -p a/net/sunrpc/addr.c b/net/sunrpc/addr.c
--- a/net/sunrpc/addr.c
+++ b/net/sunrpc/addr.c
@@ -182,7 +182,7 @@ static int rpc_parse_scope_id(const char
scope_id = dev->ifindex;
dev_put(dev);
} else {
- if (strict_strtoul(p, 10, &scope_id) == 0) {
+ if (kstrtoul(p, 10, &scope_id) == 0) {
kfree(p);
return 0;
}
@@ -322,7 +322,7 @@ size_t rpc_uaddr2sockaddr(const char *ua
c = strrchr(buf, '.');
if (unlikely(c == NULL))
return 0;
- if (unlikely(strict_strtoul(c + 1, 10, &portlo) != 0))
+ if (unlikely(kstrtoul(c + 1, 10, &portlo) != 0))
return 0;
if (unlikely(portlo > 255))
return 0;
@@ -331,7 +331,7 @@ size_t rpc_uaddr2sockaddr(const char *ua
c = strrchr(buf, '.');
if (unlikely(c == NULL))
return 0;
- if (unlikely(strict_strtoul(c + 1, 10, &porthi) != 0))
+ if (unlikely(kstrtoul(c + 1, 10, &porthi) != 0))
return 0;
if (unlikely(porthi > 255))
return 0;
diff -u -p a/net/sunrpc/auth.c b/net/sunrpc/auth.c
--- a/net/sunrpc/auth.c
+++ b/net/sunrpc/auth.c
@@ -47,7 +47,7 @@ static int param_set_hashtbl_sz(const ch
if (!val)
goto out_inval;
- ret = strict_strtoul(val, 0, &num);
+ ret = kstrtoul(val, 0, &num);
if (ret == -EINVAL)
goto out_inval;
nbits = fls(num);
diff -u -p a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
--- a/net/sunrpc/xprtsock.c
+++ b/net/sunrpc/xprtsock.c
@@ -2925,7 +2925,7 @@ static int param_set_uint_minmax(const c
if (!val)
return -EINVAL;
- ret = strict_strtoul(val, 0, &num);
+ ret = kstrtoul(val, 0, &num);
if (ret == -EINVAL || num < min || num > max)
return -EINVAL;
*((unsigned int *)kp->arg) = num;
^ permalink raw reply
* [PATCH 3/5] net/mac80211/debugfs.c: use kstrtoul, etc
From: Julia Lawall @ 2011-11-06 13:26 UTC (permalink / raw)
To: John W. Linville
Cc: kernel-janitors, Johannes Berg, David S. Miller, linux-wireless,
netdev, linux-kernel
In-Reply-To: <1320586010-21931-1-git-send-email-julia@diku.dk>
From: Julia Lawall <julia@diku.dk>
Use kstrtoul, etc instead of the now deprecated strict_strtoul, etc.
A semantic patch rule for the kstrtoul case is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression a,b;
{int,long} *c;
@@
-strict_strtoul
+kstrtoul
(a,b,c)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
net/mac80211/debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -u -p a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@ -190,7 +190,7 @@ static ssize_t uapsd_max_sp_len_write(st
return -EFAULT;
buf[len] = '\0';
- ret = strict_strtoul(buf, 0, &val);
+ ret = kstrtoul(buf, 0, &val);
if (ret)
return -EINVAL;
^ permalink raw reply
* [PATCH 4/5] net/rfkill/core.c: use kstrtoul, etc
From: Julia Lawall @ 2011-11-06 13:26 UTC (permalink / raw)
To: Johannes Berg
Cc: kernel-janitors, John W. Linville, David S. Miller,
linux-wireless, netdev, linux-kernel
In-Reply-To: <1320586010-21931-1-git-send-email-julia@diku.dk>
From: Julia Lawall <julia@diku.dk>
Use kstrtoul, etc instead of the now deprecated strict_strtoul, etc.
A semantic patch rule for the kstrtoul case is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression a,b;
{int,long} *c;
@@
-strict_strtoul
+kstrtoul
(a,b,c)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
net/rfkill/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -u -p a/net/rfkill/core.c b/net/rfkill/core.c
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -644,7 +644,7 @@ static ssize_t rfkill_soft_store(struct
if (!capable(CAP_NET_ADMIN))
return -EPERM;
- err = strict_strtoul(buf, 0, &state);
+ err = kstrtoul(buf, 0, &state);
if (err)
return err;
@@ -688,7 +688,7 @@ static ssize_t rfkill_state_store(struct
if (!capable(CAP_NET_ADMIN))
return -EPERM;
- err = strict_strtoul(buf, 0, &state);
+ err = kstrtoul(buf, 0, &state);
if (err)
return err;
^ permalink raw reply
* [PATCH 5/5] net/dns_resolver/dns_key.c: use kstrtoul, etc
From: Julia Lawall @ 2011-11-06 13:26 UTC (permalink / raw)
To: David S. Miller; +Cc: kernel-janitors, netdev, linux-kernel
In-Reply-To: <1320586010-21931-1-git-send-email-julia@diku.dk>
From: Julia Lawall <julia@diku.dk>
Use kstrtoul, etc instead of the now deprecated strict_strtoul, etc.
A semantic patch rule for the kstrtoul case is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression a,b;
{int,long} *c;
@@
-strict_strtoul
+kstrtoul
(a,b,c)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
net/dns_resolver/dns_key.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -u -p a/net/dns_resolver/dns_key.c b/net/dns_resolver/dns_key.c
--- a/net/dns_resolver/dns_key.c
+++ b/net/dns_resolver/dns_key.c
@@ -118,7 +118,7 @@ dns_resolver_instantiate(struct key *key
if (opt_vlen <= 0)
goto bad_option_value;
- ret = strict_strtoul(eq, 10, &derrno);
+ ret = kstrtoul(eq, 10, &derrno);
if (ret < 0)
goto bad_option_value;
^ permalink raw reply
* Re: [PATCH 1/5] net/batman-adv: use kstrtoul, etc
From: Marek Lindner @ 2011-11-06 14:16 UTC (permalink / raw)
To: b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Simon Wunderlich,
Julia Lawall, David S. Miller
In-Reply-To: <1320586010-21931-2-git-send-email-julia-dAYI7NvHqcQ@public.gmane.org>
On Sunday, November 06, 2011 21:26:46 Julia Lawall wrote:
> From: Julia Lawall <julia-dAYI7NvHqcQ@public.gmane.org>
>
> Use kstrtoul, etc instead of the now deprecated strict_strtoul, etc.
Thanks for the patch but we already have a patch lined up to address the
issue. It will be submitted to net-next in the next week or so.
Regards,
Marek
^ permalink raw reply
* Linux Route Cache performance tests
From: Paweł Staszewski @ 2011-11-06 15:57 UTC (permalink / raw)
To: Linux Network Development list, Eric Dumazet
Hello
I make some networking performance tests for Linux 3.1
Configuration:
Linux (pktget) ----> Linux (router) ----> Linux (Sink)
pktgen config:
clone_skb 32
pkt_size 64
delay 0
pgset "flag IPDST_RND"
pgset "dst_min 10.0.0.0"
pgset "dst_max 10.18.255.255"
pgset "config 1"
pgset "flows 256"
pgset "flowlen 8"
TX performance for this host:
eth0: RX: 0.00 P/s TX: 12346107.73 P/s TOTAL:
12346107.73 P/s
On Linux (router):
grep . /proc/sys/net/ipv4/route/*
/proc/sys/net/ipv4/route/error_burst:500
/proc/sys/net/ipv4/route/error_cost:100
grep: /proc/sys/net/ipv4/route/flush: Permission denied
/proc/sys/net/ipv4/route/gc_elasticity:4
/proc/sys/net/ipv4/route/gc_interval:60
/proc/sys/net/ipv4/route/gc_min_interval:0
/proc/sys/net/ipv4/route/gc_min_interval_ms:500
/proc/sys/net/ipv4/route/gc_thresh:2000000
/proc/sys/net/ipv4/route/gc_timeout:60
/proc/sys/net/ipv4/route/max_size:8388608
/proc/sys/net/ipv4/route/min_adv_mss:256
/proc/sys/net/ipv4/route/min_pmtu:552
/proc/sys/net/ipv4/route/mtu_expires:600
/proc/sys/net/ipv4/route/redirect_load:2
/proc/sys/net/ipv4/route/redirect_number:9
/proc/sys/net/ipv4/route/redirect_silence:2048
For the first 30secs maybee more router is forwarding ~5Mpps to the
Linux (Sink)
and some stats for this forst 30secs in attached image:
http://imageshack.us/photo/my-images/684/test1ih.png/
Left up - pktgen linux
left down - Linux router (htop)
Right up - Linux router (bwm-ng - showing pps)
Right down - Linux router (lnstat)
And all is good - performance 5Mpps until Linux router will reach ~1kk
entries
What You can see on next attached image:
http://imageshack.us/photo/my-images/24/test2id.png/
Forwarding performance drops from 5Mpps to 1,8Mpps
And after 3 - 4 minutes it will stop on 0,7Mpps
After flushing the route cache performance increase from 0.7Mpps to 6Mpps
What You can see on next attached image:
http://imageshack.us/photo/my-images/197/test3r.png/
Is it possible to turn off route cache ? and see what performance will
be without caching
Thanks
Pawel
^ permalink raw reply
* Re: Linux Route Cache performance tests
From: Eric Dumazet @ 2011-11-06 17:29 UTC (permalink / raw)
To: Paweł Staszewski; +Cc: Linux Network Development list
In-Reply-To: <4EB6AE62.5050803@itcare.pl>
Le dimanche 06 novembre 2011 à 16:57 +0100, Paweł Staszewski a écrit :
> Hello
>
>
>
> I make some networking performance tests for Linux 3.1
>
> Configuration:
>
> Linux (pktget) ----> Linux (router) ----> Linux (Sink)
>
> pktgen config:
> clone_skb 32
> pkt_size 64
> delay 0
>
> pgset "flag IPDST_RND"
> pgset "dst_min 10.0.0.0"
> pgset "dst_max 10.18.255.255"
> pgset "config 1"
> pgset "flows 256"
> pgset "flowlen 8"
>
> TX performance for this host:
> eth0: RX: 0.00 P/s TX: 12346107.73 P/s TOTAL:
> 12346107.73 P/s
>
> On Linux (router):
> grep . /proc/sys/net/ipv4/route/*
> /proc/sys/net/ipv4/route/error_burst:500
> /proc/sys/net/ipv4/route/error_cost:100
> grep: /proc/sys/net/ipv4/route/flush: Permission denied
> /proc/sys/net/ipv4/route/gc_elasticity:4
> /proc/sys/net/ipv4/route/gc_interval:60
> /proc/sys/net/ipv4/route/gc_min_interval:0
> /proc/sys/net/ipv4/route/gc_min_interval_ms:500
> /proc/sys/net/ipv4/route/gc_thresh:2000000
> /proc/sys/net/ipv4/route/gc_timeout:60
> /proc/sys/net/ipv4/route/max_size:8388608
> /proc/sys/net/ipv4/route/min_adv_mss:256
> /proc/sys/net/ipv4/route/min_pmtu:552
> /proc/sys/net/ipv4/route/mtu_expires:600
> /proc/sys/net/ipv4/route/redirect_load:2
> /proc/sys/net/ipv4/route/redirect_number:9
> /proc/sys/net/ipv4/route/redirect_silence:2048
>
> For the first 30secs maybee more router is forwarding ~5Mpps to the
> Linux (Sink)
> and some stats for this forst 30secs in attached image:
>
> http://imageshack.us/photo/my-images/684/test1ih.png/
>
> Left up - pktgen linux
> left down - Linux router (htop)
> Right up - Linux router (bwm-ng - showing pps)
> Right down - Linux router (lnstat)
>
>
> And all is good - performance 5Mpps until Linux router will reach ~1kk
> entries
> What You can see on next attached image:
>
> http://imageshack.us/photo/my-images/24/test2id.png/
>
> Forwarding performance drops from 5Mpps to 1,8Mpps
> And after 3 - 4 minutes it will stop on 0,7Mpps
>
>
> After flushing the route cache performance increase from 0.7Mpps to 6Mpps
> What You can see on next attached image:
>
> http://imageshack.us/photo/my-images/197/test3r.png/
>
> Is it possible to turn off route cache ? and see what performance will
> be without caching
>
Route cache cannot handle DDOS situation, since it will be filled,
unless you have a lot of memory.
I am not sure what you expected here. If caches misses are too frequent,
a cache is useless, whatever how its done.
If you disable route cache, you'll get poor performance in normal
situation (99.9999% of cases, non DDOS), and same performance on DDOS,
in 0.0001% cases
Trick to disable it is to use a big (and negative) rebuild_count
$ echo 3000000000 >/proc/sys/net/ipv4/rt_cache_rebuild_count
$ cat /proc/sys/net/ipv4/rt_cache_rebuild_count
-1294967296
^ permalink raw reply
* Re: Regarding Routing table in Linux kernel
From: Eric Dumazet @ 2011-11-06 17:42 UTC (permalink / raw)
To: Ajith Adapa; +Cc: netdev
In-Reply-To: <CADAe=+J-yjh-GujhVY58qKirGNANQ6fUnPdzvoQzQSxMDv7VPw@mail.gmail.com>
Le dimanche 06 novembre 2011 à 12:43 +0530, Ajith Adapa a écrit :
> Hi,
>
> I have few doubts regarding the routing table in linux kernel.
>
> 1. Why does the linux kernel use hashing table for storing routing
> entries when there is patricia trie or radix tree which is more faster
> than Hash table ?
>
I think you are mistaken. Routes are stored in a trie in recent kernels.
And route cache is scheduled to be removed at some point.
In normal situation, one hash lookup is the faster way to find a random
item, its a single memory cache line cost.
> 2. Is there any way we can test the performance of an routing
> algorithm before deploying in a real time scenario to check its
> performance ? I would like to test one of my implementations to check
> if there are any performance gains or not ?
Sorry there is no general answer. It all depends on your needs.
^ permalink raw reply
* Re: Linux Route Cache performance tests
From: Paweł Staszewski @ 2011-11-06 18:28 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linux Network Development list
In-Reply-To: <1320600597.6506.7.camel@edumazet-laptop>
W dniu 2011-11-06 18:29, Eric Dumazet pisze:
> Le dimanche 06 novembre 2011 à 16:57 +0100, Paweł Staszewski a écrit :
>> Hello
>>
>>
>>
>> I make some networking performance tests for Linux 3.1
>>
>> Configuration:
>>
>> Linux (pktget) ----> Linux (router) ----> Linux (Sink)
>>
>> pktgen config:
>> clone_skb 32
>> pkt_size 64
>> delay 0
>>
>> pgset "flag IPDST_RND"
>> pgset "dst_min 10.0.0.0"
>> pgset "dst_max 10.18.255.255"
>> pgset "config 1"
>> pgset "flows 256"
>> pgset "flowlen 8"
>>
>> TX performance for this host:
>> eth0: RX: 0.00 P/s TX: 12346107.73 P/s TOTAL:
>> 12346107.73 P/s
>>
>> On Linux (router):
>> grep . /proc/sys/net/ipv4/route/*
>> /proc/sys/net/ipv4/route/error_burst:500
>> /proc/sys/net/ipv4/route/error_cost:100
>> grep: /proc/sys/net/ipv4/route/flush: Permission denied
>> /proc/sys/net/ipv4/route/gc_elasticity:4
>> /proc/sys/net/ipv4/route/gc_interval:60
>> /proc/sys/net/ipv4/route/gc_min_interval:0
>> /proc/sys/net/ipv4/route/gc_min_interval_ms:500
>> /proc/sys/net/ipv4/route/gc_thresh:2000000
>> /proc/sys/net/ipv4/route/gc_timeout:60
>> /proc/sys/net/ipv4/route/max_size:8388608
>> /proc/sys/net/ipv4/route/min_adv_mss:256
>> /proc/sys/net/ipv4/route/min_pmtu:552
>> /proc/sys/net/ipv4/route/mtu_expires:600
>> /proc/sys/net/ipv4/route/redirect_load:2
>> /proc/sys/net/ipv4/route/redirect_number:9
>> /proc/sys/net/ipv4/route/redirect_silence:2048
>>
>> For the first 30secs maybee more router is forwarding ~5Mpps to the
>> Linux (Sink)
>> and some stats for this forst 30secs in attached image:
>>
>> http://imageshack.us/photo/my-images/684/test1ih.png/
>>
>> Left up - pktgen linux
>> left down - Linux router (htop)
>> Right up - Linux router (bwm-ng - showing pps)
>> Right down - Linux router (lnstat)
>>
>>
>> And all is good - performance 5Mpps until Linux router will reach ~1kk
>> entries
>> What You can see on next attached image:
>>
>> http://imageshack.us/photo/my-images/24/test2id.png/
>>
>> Forwarding performance drops from 5Mpps to 1,8Mpps
>> And after 3 - 4 minutes it will stop on 0,7Mpps
>>
>>
>> After flushing the route cache performance increase from 0.7Mpps to 6Mpps
>> What You can see on next attached image:
>>
>> http://imageshack.us/photo/my-images/197/test3r.png/
>>
>> Is it possible to turn off route cache ? and see what performance will
>> be without caching
>>
> Route cache cannot handle DDOS situation, since it will be filled,
> unless you have a lot of memory.
hmm
but what is DDOS situation for route cache ? new entries per sec ? total
amount of entries 1,2kk in my tests ?
Look sometimes in normal scenario You can hit
1245072 route cache entries
This is normal for BGP configurations.
The performance of route cache is ok to the point where we reach more
than 1245072 entries.
Router is starting forwarding packets with 5Mpps and ends at about
0.7Mpps when more than 1245072 entries is reached.
For my scenario
Random ip generation start at: 10.0.0.0 ends on 10.18.255.255
this is 1170450 random ip's
> I am not sure what you expected here. If caches misses are too frequent,
> a cache is useless, whatever how its done.
Yes i understand this.
> If you disable route cache, you'll get poor performance in normal
> situation (99.9999% of cases, non DDOS), and same performance on DDOS,
> in 0.0001% cases
>
> Trick to disable it is to use a big (and negative) rebuild_count
>
> $ echo 3000000000>/proc/sys/net/ipv4/rt_cache_rebuild_count
> $ cat /proc/sys/net/ipv4/rt_cache_rebuild_count
> -1294967296
Ok so disabling route cache
echo 300000000000 > /proc/sys/net/ipv4/rt_cache_rebuild_count
cat /proc/sys/net/ipv4/rt_cache_rebuild_count
-647710720
I can reach 4Mpps forwarding performance without degradation in time.
/ iface Rx
Tx Total
==============================================================================
lo: 0.00 P/s 0.00 P/s
0.00 P/s
eth1: 1.00 P/s 1.00 P/s
2.00 P/s
eth2: 0.00 P/s 3971015.09 P/s
3971015.09 P/s
eth3: 3970941.17 P/s 0.00 P/s
3970941.17 P/s
------------------------------------------------------------------------------
total: 3970942.17 P/s 3971016.09 P/s
7941958.26 P/s
lnstat -c -1 -i 1 -f rt_cache -k entries
rt_cache|
entries|
8|
6|
5|
10|
5|
7|
7|
11|
5|
11|
11|
6|
7|
6|
So with disabled route cache performance is better for over 1kk route
cache entries.
But it is static.
So i have the same performance now for generated 10k,50k,100k,1kk random
ip's
So yes in scenarion when You count that route cache will never reach
over 1kk entries performance with route cache enabled is 2x more that
with disabled.
But when somehow - You will reach over 1kk entries in route cache -
router almost stops forwarding traffic.
Thanks
Pawel
>
> --
> 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
>
>
^ permalink raw reply
* [PATCH] usbnet: fix oops in usbnet_start_xmit
From: Konstantin Khlebnikov @ 2011-11-06 19:33 UTC (permalink / raw)
To: Oliver Neukum; +Cc: netdev, David S. Miller, devel, Michael Riesch
This patch fixes the bug added in commit v3.1-rc7-1055-gf9b491e
SKB can be NULL at this point, at least for cdc-ncm.
Let's call skb_tx_timestamp() after driver specific tx-fixup hacks.
Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
---
drivers/net/usb/usbnet.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 7d60821..485be70 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -1057,8 +1057,6 @@ netdev_tx_t usbnet_start_xmit (struct sk_buff *skb,
unsigned long flags;
int retval;
- skb_tx_timestamp(skb);
-
// some devices want funky USB-level framing, for
// win32 driver (usually) and/or hardware quirks
if (info->tx_fixup) {
@@ -1075,6 +1073,8 @@ netdev_tx_t usbnet_start_xmit (struct sk_buff *skb,
}
length = skb->len;
+ skb_tx_timestamp(skb);
+
if (!(urb = usb_alloc_urb (0, GFP_ATOMIC))) {
netif_dbg(dev, tx_err, dev->net, "no urb\n");
goto drop;
^ permalink raw reply related
* Re: Linux Route Cache performance tests
From: Eric Dumazet @ 2011-11-06 18:48 UTC (permalink / raw)
To: Paweł Staszewski; +Cc: Linux Network Development list
In-Reply-To: <4EB6D1D8.8040604@itcare.pl>
Le dimanche 06 novembre 2011 à 19:28 +0100, Paweł Staszewski a écrit :
> W dniu 2011-11-06 18:29, Eric Dumazet pisze:
> > Le dimanche 06 novembre 2011 à 16:57 +0100, Paweł Staszewski a écrit :
> >> Hello
> >>
> >>
> >>
> >> I make some networking performance tests for Linux 3.1
> >>
> >> Configuration:
> >>
> >> Linux (pktget) ----> Linux (router) ----> Linux (Sink)
> >>
> >> pktgen config:
> >> clone_skb 32
> >> pkt_size 64
> >> delay 0
> >>
> >> pgset "flag IPDST_RND"
> >> pgset "dst_min 10.0.0.0"
> >> pgset "dst_max 10.18.255.255"
> >> pgset "config 1"
> >> pgset "flows 256"
> >> pgset "flowlen 8"
> >>
> >> TX performance for this host:
> >> eth0: RX: 0.00 P/s TX: 12346107.73 P/s TOTAL:
> >> 12346107.73 P/s
> >>
> >> On Linux (router):
> >> grep . /proc/sys/net/ipv4/route/*
> >> /proc/sys/net/ipv4/route/error_burst:500
> >> /proc/sys/net/ipv4/route/error_cost:100
> >> grep: /proc/sys/net/ipv4/route/flush: Permission denied
> >> /proc/sys/net/ipv4/route/gc_elasticity:4
> >> /proc/sys/net/ipv4/route/gc_interval:60
> >> /proc/sys/net/ipv4/route/gc_min_interval:0
> >> /proc/sys/net/ipv4/route/gc_min_interval_ms:500
> >> /proc/sys/net/ipv4/route/gc_thresh:2000000
> >> /proc/sys/net/ipv4/route/gc_timeout:60
> >> /proc/sys/net/ipv4/route/max_size:8388608
> >> /proc/sys/net/ipv4/route/min_adv_mss:256
> >> /proc/sys/net/ipv4/route/min_pmtu:552
> >> /proc/sys/net/ipv4/route/mtu_expires:600
> >> /proc/sys/net/ipv4/route/redirect_load:2
> >> /proc/sys/net/ipv4/route/redirect_number:9
> >> /proc/sys/net/ipv4/route/redirect_silence:2048
> >>
> >> For the first 30secs maybee more router is forwarding ~5Mpps to the
> >> Linux (Sink)
> >> and some stats for this forst 30secs in attached image:
> >>
> >> http://imageshack.us/photo/my-images/684/test1ih.png/
> >>
> >> Left up - pktgen linux
> >> left down - Linux router (htop)
> >> Right up - Linux router (bwm-ng - showing pps)
> >> Right down - Linux router (lnstat)
> >>
> >>
> >> And all is good - performance 5Mpps until Linux router will reach ~1kk
> >> entries
> >> What You can see on next attached image:
> >>
> >> http://imageshack.us/photo/my-images/24/test2id.png/
> >>
> >> Forwarding performance drops from 5Mpps to 1,8Mpps
> >> And after 3 - 4 minutes it will stop on 0,7Mpps
> >>
> >>
> >> After flushing the route cache performance increase from 0.7Mpps to 6Mpps
> >> What You can see on next attached image:
> >>
> >> http://imageshack.us/photo/my-images/197/test3r.png/
> >>
> >> Is it possible to turn off route cache ? and see what performance will
> >> be without caching
> >>
> > Route cache cannot handle DDOS situation, since it will be filled,
> > unless you have a lot of memory.
> hmm
> but what is DDOS situation for route cache ? new entries per sec ? total
> amount of entries 1,2kk in my tests ?
> Look sometimes in normal scenario You can hit
> 1245072 route cache entries
> This is normal for BGP configurations.
>
Then figure out the right tunables for your machine ?
Its not a laptop or average server setup, so you need to allow your
kernel to consume a fair amount of memory for the route cache.
Or accept low performance :(
> The performance of route cache is ok to the point where we reach more
> than 1245072 entries.
> Router is starting forwarding packets with 5Mpps and ends at about
> 0.7Mpps when more than 1245072 entries is reached.
> For my scenario
> Random ip generation start at: 10.0.0.0 ends on 10.18.255.255
> this is 1170450 random ip's
>
I have no problem with 4 millions entries in route cache, with full
performance, not 80%.
You currently have one hash table with 524288 entries
(before you changed /proc/sys/net/ipv4/route/gc_thresh)
Its not optimal for your workload, because you have many slots with 4
chained items, performance sucks.
You have to boot your machine with "rhash_entries=2097152", so that
average chain length is less than 1
Your problem is then solved :
# grep . /proc/sys/net/ipv4/route/*
/proc/sys/net/ipv4/route/error_burst:5000
/proc/sys/net/ipv4/route/error_cost:1000
/proc/sys/net/ipv4/route/gc_elasticity:8
/proc/sys/net/ipv4/route/gc_min_interval:0
/proc/sys/net/ipv4/route/gc_min_interval_ms:500
/proc/sys/net/ipv4/route/gc_thresh:2097152
/proc/sys/net/ipv4/route/gc_timeout:300
/proc/sys/net/ipv4/route/max_size:33554432
/proc/sys/net/ipv4/route/min_adv_mss:256
/proc/sys/net/ipv4/route/min_pmtu:552
/proc/sys/net/ipv4/route/mtu_expires:600
/proc/sys/net/ipv4/route/redirect_load:20
/proc/sys/net/ipv4/route/redirect_number:9
/proc/sys/net/ipv4/route/redirect_silence:20480
^ permalink raw reply
* Re: Linux Route Cache performance tests
From: Paweł Staszewski @ 2011-11-06 19:20 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linux Network Development list
In-Reply-To: <1320605326.6506.27.camel@edumazet-laptop>
W dniu 2011-11-06 19:48, Eric Dumazet pisze:
> Le dimanche 06 novembre 2011 à 19:28 +0100, Paweł Staszewski a écrit :
>> W dniu 2011-11-06 18:29, Eric Dumazet pisze:
>>> Le dimanche 06 novembre 2011 à 16:57 +0100, Paweł Staszewski a écrit :
>>>> Hello
>>>>
>>>>
>>>>
>>>> I make some networking performance tests for Linux 3.1
>>>>
>>>> Configuration:
>>>>
>>>> Linux (pktget) ----> Linux (router) ----> Linux (Sink)
>>>>
>>>> pktgen config:
>>>> clone_skb 32
>>>> pkt_size 64
>>>> delay 0
>>>>
>>>> pgset "flag IPDST_RND"
>>>> pgset "dst_min 10.0.0.0"
>>>> pgset "dst_max 10.18.255.255"
>>>> pgset "config 1"
>>>> pgset "flows 256"
>>>> pgset "flowlen 8"
>>>>
>>>> TX performance for this host:
>>>> eth0: RX: 0.00 P/s TX: 12346107.73 P/s TOTAL:
>>>> 12346107.73 P/s
>>>>
>>>> On Linux (router):
>>>> grep . /proc/sys/net/ipv4/route/*
>>>> /proc/sys/net/ipv4/route/error_burst:500
>>>> /proc/sys/net/ipv4/route/error_cost:100
>>>> grep: /proc/sys/net/ipv4/route/flush: Permission denied
>>>> /proc/sys/net/ipv4/route/gc_elasticity:4
>>>> /proc/sys/net/ipv4/route/gc_interval:60
>>>> /proc/sys/net/ipv4/route/gc_min_interval:0
>>>> /proc/sys/net/ipv4/route/gc_min_interval_ms:500
>>>> /proc/sys/net/ipv4/route/gc_thresh:2000000
>>>> /proc/sys/net/ipv4/route/gc_timeout:60
>>>> /proc/sys/net/ipv4/route/max_size:8388608
>>>> /proc/sys/net/ipv4/route/min_adv_mss:256
>>>> /proc/sys/net/ipv4/route/min_pmtu:552
>>>> /proc/sys/net/ipv4/route/mtu_expires:600
>>>> /proc/sys/net/ipv4/route/redirect_load:2
>>>> /proc/sys/net/ipv4/route/redirect_number:9
>>>> /proc/sys/net/ipv4/route/redirect_silence:2048
>>>>
>>>> For the first 30secs maybee more router is forwarding ~5Mpps to the
>>>> Linux (Sink)
>>>> and some stats for this forst 30secs in attached image:
>>>>
>>>> http://imageshack.us/photo/my-images/684/test1ih.png/
>>>>
>>>> Left up - pktgen linux
>>>> left down - Linux router (htop)
>>>> Right up - Linux router (bwm-ng - showing pps)
>>>> Right down - Linux router (lnstat)
>>>>
>>>>
>>>> And all is good - performance 5Mpps until Linux router will reach ~1kk
>>>> entries
>>>> What You can see on next attached image:
>>>>
>>>> http://imageshack.us/photo/my-images/24/test2id.png/
>>>>
>>>> Forwarding performance drops from 5Mpps to 1,8Mpps
>>>> And after 3 - 4 minutes it will stop on 0,7Mpps
>>>>
>>>>
>>>> After flushing the route cache performance increase from 0.7Mpps to 6Mpps
>>>> What You can see on next attached image:
>>>>
>>>> http://imageshack.us/photo/my-images/197/test3r.png/
>>>>
>>>> Is it possible to turn off route cache ? and see what performance will
>>>> be without caching
>>>>
>>> Route cache cannot handle DDOS situation, since it will be filled,
>>> unless you have a lot of memory.
>> hmm
>> but what is DDOS situation for route cache ? new entries per sec ? total
>> amount of entries 1,2kk in my tests ?
>> Look sometimes in normal scenario You can hit
>> 1245072 route cache entries
>> This is normal for BGP configurations.
>>
> Then figure out the right tunables for your machine ?
>
> Its not a laptop or average server setup, so you need to allow your
> kernel to consume a fair amount of memory for the route cache.
Yes this parameters was special not tuned :)
To see what is the route cache performance limit
Because there was no optimal parameters for this test :)
no matter what i tuned results are always the same
performance drops from 5Mpps to 0.7Mpps without tuning sysctl
And with tuned parameters i can reach the same as turning off route
cache - when running this tests.
So Yes Tuned performance is better
performance drops from 5Mpps to 0.7Mpps - without tuning
and from 5Mpps to 3,7Mpps with tuned sysctl - so a little less than with
turned off route cache
So the point of this test was figure out how much of route cache entries
Linux can handle without dropping performance.
> Or accept low performance :(
Never :)
>> The performance of route cache is ok to the point where we reach more
>> than 1245072 entries.
>> Router is starting forwarding packets with 5Mpps and ends at about
>> 0.7Mpps when more than 1245072 entries is reached.
>> For my scenario
>> Random ip generation start at: 10.0.0.0 ends on 10.18.255.255
>> this is 1170450 random ip's
>>
> I have no problem with 4 millions entries in route cache, with full
> performance, not 80%.
>
>
> You currently have one hash table with 524288 entries
> (before you changed /proc/sys/net/ipv4/route/gc_thresh)
>
> Its not optimal for your workload, because you have many slots with 4
> chained items, performance sucks.
>
> You have to boot your machine with "rhash_entries=2097152", so that
> average chain length is less than 1
>
> Your problem is then solved :
>
> # grep . /proc/sys/net/ipv4/route/*
> /proc/sys/net/ipv4/route/error_burst:5000
> /proc/sys/net/ipv4/route/error_cost:1000
> /proc/sys/net/ipv4/route/gc_elasticity:8
> /proc/sys/net/ipv4/route/gc_min_interval:0
> /proc/sys/net/ipv4/route/gc_min_interval_ms:500
> /proc/sys/net/ipv4/route/gc_thresh:2097152
> /proc/sys/net/ipv4/route/gc_timeout:300
> /proc/sys/net/ipv4/route/max_size:33554432
> /proc/sys/net/ipv4/route/min_adv_mss:256
> /proc/sys/net/ipv4/route/min_pmtu:552
> /proc/sys/net/ipv4/route/mtu_expires:600
> /proc/sys/net/ipv4/route/redirect_load:20
> /proc/sys/net/ipv4/route/redirect_number:9
> /proc/sys/net/ipv4/route/redirect_silence:20480
>
>
> --
> 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
>
>
^ permalink raw reply
* Re: Linux Route Cache performance tests
From: Eric Dumazet @ 2011-11-06 19:38 UTC (permalink / raw)
To: Paweł Staszewski; +Cc: Linux Network Development list
In-Reply-To: <4EB6DE06.7050009@itcare.pl>
Le dimanche 06 novembre 2011 à 20:20 +0100, Paweł Staszewski a écrit :
> W dniu 2011-11-06 19:48, Eric Dumazet pisze:
> > Le dimanche 06 novembre 2011 à 19:28 +0100, Paweł Staszewski a écrit :
> >> W dniu 2011-11-06 18:29, Eric Dumazet pisze:
> >>> Le dimanche 06 novembre 2011 à 16:57 +0100, Paweł Staszewski a écrit :
> >>>> Hello
> >>>>
> >>>>
> >>>>
> >>>> I make some networking performance tests for Linux 3.1
> >>>>
> >>>> Configuration:
> >>>>
> >>>> Linux (pktget) ----> Linux (router) ----> Linux (Sink)
> >>>>
> >>>> pktgen config:
> >>>> clone_skb 32
> >>>> pkt_size 64
> >>>> delay 0
> >>>>
> >>>> pgset "flag IPDST_RND"
> >>>> pgset "dst_min 10.0.0.0"
> >>>> pgset "dst_max 10.18.255.255"
> >>>> pgset "config 1"
> >>>> pgset "flows 256"
> >>>> pgset "flowlen 8"
> >>>>
> >>>> TX performance for this host:
> >>>> eth0: RX: 0.00 P/s TX: 12346107.73 P/s TOTAL:
> >>>> 12346107.73 P/s
> >>>>
> >>>> On Linux (router):
> >>>> grep . /proc/sys/net/ipv4/route/*
> >>>> /proc/sys/net/ipv4/route/error_burst:500
> >>>> /proc/sys/net/ipv4/route/error_cost:100
> >>>> grep: /proc/sys/net/ipv4/route/flush: Permission denied
> >>>> /proc/sys/net/ipv4/route/gc_elasticity:4
> >>>> /proc/sys/net/ipv4/route/gc_interval:60
> >>>> /proc/sys/net/ipv4/route/gc_min_interval:0
> >>>> /proc/sys/net/ipv4/route/gc_min_interval_ms:500
> >>>> /proc/sys/net/ipv4/route/gc_thresh:2000000
> >>>> /proc/sys/net/ipv4/route/gc_timeout:60
> >>>> /proc/sys/net/ipv4/route/max_size:8388608
> >>>> /proc/sys/net/ipv4/route/min_adv_mss:256
> >>>> /proc/sys/net/ipv4/route/min_pmtu:552
> >>>> /proc/sys/net/ipv4/route/mtu_expires:600
> >>>> /proc/sys/net/ipv4/route/redirect_load:2
> >>>> /proc/sys/net/ipv4/route/redirect_number:9
> >>>> /proc/sys/net/ipv4/route/redirect_silence:2048
> >>>>
> >>>> For the first 30secs maybee more router is forwarding ~5Mpps to the
> >>>> Linux (Sink)
> >>>> and some stats for this forst 30secs in attached image:
> >>>>
> >>>> http://imageshack.us/photo/my-images/684/test1ih.png/
> >>>>
> >>>> Left up - pktgen linux
> >>>> left down - Linux router (htop)
> >>>> Right up - Linux router (bwm-ng - showing pps)
> >>>> Right down - Linux router (lnstat)
> >>>>
> >>>>
> >>>> And all is good - performance 5Mpps until Linux router will reach ~1kk
> >>>> entries
> >>>> What You can see on next attached image:
> >>>>
> >>>> http://imageshack.us/photo/my-images/24/test2id.png/
> >>>>
> >>>> Forwarding performance drops from 5Mpps to 1,8Mpps
> >>>> And after 3 - 4 minutes it will stop on 0,7Mpps
> >>>>
> >>>>
> >>>> After flushing the route cache performance increase from 0.7Mpps to 6Mpps
> >>>> What You can see on next attached image:
> >>>>
> >>>> http://imageshack.us/photo/my-images/197/test3r.png/
> >>>>
> >>>> Is it possible to turn off route cache ? and see what performance will
> >>>> be without caching
> >>>>
> >>> Route cache cannot handle DDOS situation, since it will be filled,
> >>> unless you have a lot of memory.
> >> hmm
> >> but what is DDOS situation for route cache ? new entries per sec ? total
> >> amount of entries 1,2kk in my tests ?
> >> Look sometimes in normal scenario You can hit
> >> 1245072 route cache entries
> >> This is normal for BGP configurations.
> >>
> > Then figure out the right tunables for your machine ?
> >
> > Its not a laptop or average server setup, so you need to allow your
> > kernel to consume a fair amount of memory for the route cache.
> Yes this parameters was special not tuned :)
> To see what is the route cache performance limit
>
Hmm, I thought you were asking for help on netdev ?
> Because there was no optimal parameters for this test :)
> no matter what i tuned results are always the same
> performance drops from 5Mpps to 0.7Mpps without tuning sysctl
>
> And with tuned parameters i can reach the same as turning off route
> cache - when running this tests.
> So Yes Tuned performance is better
> performance drops from 5Mpps to 0.7Mpps - without tuning
> and from 5Mpps to 3,7Mpps with tuned sysctl - so a little less than with
> turned off route cache
>
> So the point of this test was figure out how much of route cache entries
> Linux can handle without dropping performance.
No need to even do a bench, its pretty easy to understand how a hash
table is handled.
Allowing long chains is not good.
With your 512k slots hash table, you cannot expect handling 1.4M routes
with optimal performance. End of story.
Since route hash table is allocated at boot time, only way to change its
size is using "rhash_entries=2097152" boot parameter.
If it still doesnt fly, try with "rhash_entries=4194304"
^ permalink raw reply
* Re: ixgbe: compilation failed if CONFIG_PCI_IOV isn't set
From: Or Gerlitz @ 2011-11-06 19:51 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: Alexander Kolesen, netdev@vger.kernel.org, Rose, Gregory V,
Li, Sibai
In-Reply-To: <1320549540.5386.29.camel@jtkirshe-mobl>
On Sun, Nov 6, 2011 at 5:18 AM, Jeff Kirsher
<jeffrey.t.kirsher@intel.com> wrote:
> Was with the latest kernel from David Miller's net.gt tree? I just ask
> because I just pushed a patch (a couple of days ago) to resolve
> compilation errors when CONFIG_PCI_IOV is not enabled by Greg Rose.
In my case it was with Linus tree from github
Or.
^ permalink raw reply
* Re: Linux Route Cache performance tests
From: Paweł Staszewski @ 2011-11-06 20:25 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linux Network Development list
In-Reply-To: <1320608290.6506.33.camel@edumazet-laptop>
W dniu 2011-11-06 20:38, Eric Dumazet pisze:
> Le dimanche 06 novembre 2011 à 20:20 +0100, Paweł Staszewski a écrit :
>> W dniu 2011-11-06 19:48, Eric Dumazet pisze:
>>> Le dimanche 06 novembre 2011 à 19:28 +0100, Paweł Staszewski a écrit :
>>>> W dniu 2011-11-06 18:29, Eric Dumazet pisze:
>>>>> Le dimanche 06 novembre 2011 à 16:57 +0100, Paweł Staszewski a écrit :
>>>>>> Hello
>>>>>>
>>>>>>
>>>>>>
>>>>>> I make some networking performance tests for Linux 3.1
>>>>>>
>>>>>> Configuration:
>>>>>>
>>>>>> Linux (pktget) ----> Linux (router) ----> Linux (Sink)
>>>>>>
>>>>>> pktgen config:
>>>>>> clone_skb 32
>>>>>> pkt_size 64
>>>>>> delay 0
>>>>>>
>>>>>> pgset "flag IPDST_RND"
>>>>>> pgset "dst_min 10.0.0.0"
>>>>>> pgset "dst_max 10.18.255.255"
>>>>>> pgset "config 1"
>>>>>> pgset "flows 256"
>>>>>> pgset "flowlen 8"
>>>>>>
>>>>>> TX performance for this host:
>>>>>> eth0: RX: 0.00 P/s TX: 12346107.73 P/s TOTAL:
>>>>>> 12346107.73 P/s
>>>>>>
>>>>>> On Linux (router):
>>>>>> grep . /proc/sys/net/ipv4/route/*
>>>>>> /proc/sys/net/ipv4/route/error_burst:500
>>>>>> /proc/sys/net/ipv4/route/error_cost:100
>>>>>> grep: /proc/sys/net/ipv4/route/flush: Permission denied
>>>>>> /proc/sys/net/ipv4/route/gc_elasticity:4
>>>>>> /proc/sys/net/ipv4/route/gc_interval:60
>>>>>> /proc/sys/net/ipv4/route/gc_min_interval:0
>>>>>> /proc/sys/net/ipv4/route/gc_min_interval_ms:500
>>>>>> /proc/sys/net/ipv4/route/gc_thresh:2000000
>>>>>> /proc/sys/net/ipv4/route/gc_timeout:60
>>>>>> /proc/sys/net/ipv4/route/max_size:8388608
>>>>>> /proc/sys/net/ipv4/route/min_adv_mss:256
>>>>>> /proc/sys/net/ipv4/route/min_pmtu:552
>>>>>> /proc/sys/net/ipv4/route/mtu_expires:600
>>>>>> /proc/sys/net/ipv4/route/redirect_load:2
>>>>>> /proc/sys/net/ipv4/route/redirect_number:9
>>>>>> /proc/sys/net/ipv4/route/redirect_silence:2048
>>>>>>
>>>>>> For the first 30secs maybee more router is forwarding ~5Mpps to the
>>>>>> Linux (Sink)
>>>>>> and some stats for this forst 30secs in attached image:
>>>>>>
>>>>>> http://imageshack.us/photo/my-images/684/test1ih.png/
>>>>>>
>>>>>> Left up - pktgen linux
>>>>>> left down - Linux router (htop)
>>>>>> Right up - Linux router (bwm-ng - showing pps)
>>>>>> Right down - Linux router (lnstat)
>>>>>>
>>>>>>
>>>>>> And all is good - performance 5Mpps until Linux router will reach ~1kk
>>>>>> entries
>>>>>> What You can see on next attached image:
>>>>>>
>>>>>> http://imageshack.us/photo/my-images/24/test2id.png/
>>>>>>
>>>>>> Forwarding performance drops from 5Mpps to 1,8Mpps
>>>>>> And after 3 - 4 minutes it will stop on 0,7Mpps
>>>>>>
>>>>>>
>>>>>> After flushing the route cache performance increase from 0.7Mpps to 6Mpps
>>>>>> What You can see on next attached image:
>>>>>>
>>>>>> http://imageshack.us/photo/my-images/197/test3r.png/
>>>>>>
>>>>>> Is it possible to turn off route cache ? and see what performance will
>>>>>> be without caching
>>>>>>
>>>>> Route cache cannot handle DDOS situation, since it will be filled,
>>>>> unless you have a lot of memory.
>>>> hmm
>>>> but what is DDOS situation for route cache ? new entries per sec ? total
>>>> amount of entries 1,2kk in my tests ?
>>>> Look sometimes in normal scenario You can hit
>>>> 1245072 route cache entries
>>>> This is normal for BGP configurations.
>>>>
>>> Then figure out the right tunables for your machine ?
>>>
>>> Its not a laptop or average server setup, so you need to allow your
>>> kernel to consume a fair amount of memory for the route cache.
>> Yes this parameters was special not tuned :)
>> To see what is the route cache performance limit
>>
> Hmm, I thought you were asking for help on netdev ?
Title was tests :)
And yes maybee some help that You give me about understanding how kernel
works with and without route cache.
>
>> Because there was no optimal parameters for this test :)
>> no matter what i tuned results are always the same
>> performance drops from 5Mpps to 0.7Mpps without tuning sysctl
>>
>> And with tuned parameters i can reach the same as turning off route
>> cache - when running this tests.
>> So Yes Tuned performance is better
>> performance drops from 5Mpps to 0.7Mpps - without tuning
>> and from 5Mpps to 3,7Mpps with tuned sysctl - so a little less than with
>> turned off route cache
>>
>> So the point of this test was figure out how much of route cache entries
>> Linux can handle without dropping performance.
> No need to even do a bench, its pretty easy to understand how a hash
> table is handled.
>
> Allowing long chains is not good.
>
> With your 512k slots hash table, you cannot expect handling 1.4M routes
> with optimal performance. End of story.
>
> Since route hash table is allocated at boot time, only way to change its
> size is using "rhash_entries=2097152" boot parameter.
>
> If it still doesnt fly, try with "rhash_entries=4194304"
Yes with this is a little problem i think with kernel 3.1 because
dmesg | egrep '(rhash)|(route)'
[ 0.000000] Command line: root=/dev/md2 rhash_entries=2097152
[ 0.000000] Kernel command line: root=/dev/md2 rhash_entries=2097152
[ 4.697294] IP route cache hash table entries: 524288 (order: 10,
4194304 bytes)
Thanks
Pawel
>
>
> --
> 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
>
>
^ permalink raw reply
* Re: Linux Route Cache performance tests
From: Eric Dumazet @ 2011-11-06 21:26 UTC (permalink / raw)
To: Paweł Staszewski; +Cc: Linux Network Development list
In-Reply-To: <4EB6ED2E.1070106@itcare.pl>
Le dimanche 06 novembre 2011 à 21:25 +0100, Paweł Staszewski a écrit :
> Yes with this is a little problem i think with kernel 3.1 because
> dmesg | egrep '(rhash)|(route)'
> [ 0.000000] Command line: root=/dev/md2 rhash_entries=2097152
> [ 0.000000] Kernel command line: root=/dev/md2 rhash_entries=2097152
> [ 4.697294] IP route cache hash table entries: 524288 (order: 10,
> 4194304 bytes)
>
>
Dont tell me you _still_ use a 32bit kernel ?
If so, you need to tweak alloc_large_system_hash() to use vmalloc,
because you hit MAX_ORDER (10) page allocations.
But considering LOWMEM is about 700 Mbytes, you wont be able to create a
lot of route cache entries.
Come on, do us a favor, and enter new era of computing.
^ permalink raw reply
* Re: Linux Route Cache performance tests
From: Paweł Staszewski @ 2011-11-06 21:57 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linux Network Development list
In-Reply-To: <1320614788.6506.38.camel@edumazet-laptop>
W dniu 2011-11-06 22:26, Eric Dumazet pisze:
> Le dimanche 06 novembre 2011 à 21:25 +0100, Paweł Staszewski a écrit :
>> Yes with this is a little problem i think with kernel 3.1 because
>> dmesg | egrep '(rhash)|(route)'
>> [ 0.000000] Command line: root=/dev/md2 rhash_entries=2097152
>> [ 0.000000] Kernel command line: root=/dev/md2 rhash_entries=2097152
>> [ 4.697294] IP route cache hash table entries: 524288 (order: 10,
>> 4194304 bytes)
>>
>>
> Dont tell me you _still_ use a 32bit kernel ?
no it is 64bit :)
Linux localhost 3.1.0 #16 SMP Sun Nov 6 18:09:48 CET 2011 x86_64 Intel(R)
:)
> If so, you need to tweak alloc_large_system_hash() to use vmalloc,
> because you hit MAX_ORDER (10) page allocations.
funny then :)
Maybee i turned off too many kernel features
> But considering LOWMEM is about 700 Mbytes, you wont be able to create a
> lot of route cache entries.
>
> Come on, do us a favor, and enter new era of computing.
>
>
>
>
>
^ permalink raw reply
* [PATCH] net, wireless, mwifiex: Fix mem leak in mwifiex_update_curr_bss_params()
From: Jesper Juhl @ 2011-11-06 21:58 UTC (permalink / raw)
To: linux-wireless, netdev, linux-kernel; +Cc: John W. Linville, Bing Zhao
If kmemdup() fails we leak the memory allocated to bss_desc.
This patch fixes the leak.
I also removed the pointless default assignment of 'NULL' to 'bss_desc'
while I was there anyway.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
drivers/net/wireless/mwifiex/scan.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
note: patch is compile tested only since I don't have the hardware.
diff --git a/drivers/net/wireless/mwifiex/scan.c b/drivers/net/wireless/mwifiex/scan.c
index dae8dbb..8a3f959 100644
--- a/drivers/net/wireless/mwifiex/scan.c
+++ b/drivers/net/wireless/mwifiex/scan.c
@@ -1469,7 +1469,7 @@ mwifiex_update_curr_bss_params(struct mwifiex_private *priv, u8 *bssid,
s32 rssi, const u8 *ie_buf, size_t ie_len,
u16 beacon_period, u16 cap_info_bitmap, u8 band)
{
- struct mwifiex_bssdescriptor *bss_desc = NULL;
+ struct mwifiex_bssdescriptor *bss_desc;
int ret;
unsigned long flags;
u8 *beacon_ie;
@@ -1484,6 +1484,7 @@ mwifiex_update_curr_bss_params(struct mwifiex_private *priv, u8 *bssid,
beacon_ie = kmemdup(ie_buf, ie_len, GFP_KERNEL);
if (!beacon_ie) {
+ kfree(bss_desc);
dev_err(priv->adapter->dev, " failed to alloc beacon_ie\n");
return -ENOMEM;
}
--
1.7.7.2
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* Re: [PATCH] net, wireless, mwifiex: Fix mem leak in mwifiex_update_curr_bss_params()
From: Srivatsa S. Bhat @ 2011-11-06 22:24 UTC (permalink / raw)
To: Jesper Juhl
Cc: linux-wireless, netdev, linux-kernel, John W. Linville, Bing Zhao
In-Reply-To: <alpine.LNX.2.00.1111062255310.5763@swampdragon.chaosbits.net>
On 11/07/2011 03:28 AM, Jesper Juhl wrote:
> If kmemdup() fails we leak the memory allocated to bss_desc.
> This patch fixes the leak.
> I also removed the pointless default assignment of 'NULL' to 'bss_desc'
> while I was there anyway.
>
> Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Looks good to me.
Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Thanks,
Srivatsa S. Bhat
> ---
> drivers/net/wireless/mwifiex/scan.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> note: patch is compile tested only since I don't have the hardware.
>
> diff --git a/drivers/net/wireless/mwifiex/scan.c b/drivers/net/wireless/mwifiex/scan.c
> index dae8dbb..8a3f959 100644
> --- a/drivers/net/wireless/mwifiex/scan.c
> +++ b/drivers/net/wireless/mwifiex/scan.c
> @@ -1469,7 +1469,7 @@ mwifiex_update_curr_bss_params(struct mwifiex_private *priv, u8 *bssid,
> s32 rssi, const u8 *ie_buf, size_t ie_len,
> u16 beacon_period, u16 cap_info_bitmap, u8 band)
> {
> - struct mwifiex_bssdescriptor *bss_desc = NULL;
> + struct mwifiex_bssdescriptor *bss_desc;
> int ret;
> unsigned long flags;
> u8 *beacon_ie;
> @@ -1484,6 +1484,7 @@ mwifiex_update_curr_bss_params(struct mwifiex_private *priv, u8 *bssid,
>
> beacon_ie = kmemdup(ie_buf, ie_len, GFP_KERNEL);
> if (!beacon_ie) {
> + kfree(bss_desc);
> dev_err(priv->adapter->dev, " failed to alloc beacon_ie\n");
> return -ENOMEM;
> }
^ permalink raw reply
* [SPAM:#] Business proposal
From: LEUNG Cheung @ 2011-11-06 22:16 UTC (permalink / raw)
Hello,
I am sending you this brief letter to solicit your partnership to transfer a total sum of $22.5 million Dollars
from Hong Kong to your country. We shall share in the ratio of 40/60 (40% for you and 60% for me) when
the transfer is finally made, more details and procedures will be sent to you when I receive your response.
Thank you and have a great day.
Best Regards,
Mr. LEUNG Cheung
^ permalink raw reply
* Re: Linux Route Cache performance tests
From: Eric Dumazet @ 2011-11-06 23:08 UTC (permalink / raw)
To: Paweł Staszewski; +Cc: Linux Network Development list
In-Reply-To: <4EB702D3.1090703@itcare.pl>
Le dimanche 06 novembre 2011 à 22:57 +0100, Paweł Staszewski a écrit :
> W dniu 2011-11-06 22:26, Eric Dumazet pisze:
> > Le dimanche 06 novembre 2011 à 21:25 +0100, Paweł Staszewski a écrit :
> >> Yes with this is a little problem i think with kernel 3.1 because
> >> dmesg | egrep '(rhash)|(route)'
> >> [ 0.000000] Command line: root=/dev/md2 rhash_entries=2097152
> >> [ 0.000000] Kernel command line: root=/dev/md2 rhash_entries=2097152
> >> [ 4.697294] IP route cache hash table entries: 524288 (order: 10,
> >> 4194304 bytes)
> >>
> >>
> > Dont tell me you _still_ use a 32bit kernel ?
> no it is 64bit :)
> Linux localhost 3.1.0 #16 SMP Sun Nov 6 18:09:48 CET 2011 x86_64 Intel(R)
> :)
>
> > If so, you need to tweak alloc_large_system_hash() to use vmalloc,
> > because you hit MAX_ORDER (10) page allocations.
> funny then :)
> Maybee i turned off too many kernel features
> > But considering LOWMEM is about 700 Mbytes, you wont be able to create a
> > lot of route cache entries.
> >
> > Come on, do us a favor, and enter new era of computing.
OK, then your kernel is not CONFIG_NUMA enabled
It seems strange given you probably have a NUMA machine (24 cpus)
If so, your choices are :
1) enable CONFIG_NUMA. Really this is a must given the workload of your
machine.
2) Or : you need to add "hashdist=1" on boot params
and patch your kernel with following patch :
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 9dd443d..07f86e0 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5362,7 +5362,6 @@ int percpu_pagelist_fraction_sysctl_handler(ctl_table *table, int write,
int hashdist = HASHDIST_DEFAULT;
-#ifdef CONFIG_NUMA
static int __init set_hashdist(char *str)
{
if (!str)
@@ -5371,7 +5370,6 @@ static int __init set_hashdist(char *str)
return 1;
}
__setup("hashdist=", set_hashdist);
-#endif
/*
* allocate a large system hash table from bootmem
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox