* 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
* 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 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: 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: 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: 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 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
* [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: 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
* 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: 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
* 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: [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
* [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
* [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 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 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 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 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
* -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
* 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
* Regarding Routing table in Linux kernel
From: Ajith Adapa @ 2011-11-06 7:13 UTC (permalink / raw)
To: netdev
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 ?
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 ?
Regards,
Ajith
^ permalink raw reply
* Re: ixgbe: compilation failed if CONFIG_PCI_IOV isn't set
From: Jeff Kirsher @ 2011-11-06 3:18 UTC (permalink / raw)
To: Alexander Kolesen; +Cc: netdev@vger.kernel.org, Rose, Gregory V, Li, Sibai
In-Reply-To: <20111106000819.GC12157@vaio>
[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]
On Sat, 2011-11-05 at 17:08 -0700, Alexander Kolesen wrote:
> Hello.
> I've tried to build vanilla kernel (HEAD: 5c8a0fbb) and got the error:
>
> 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:3: 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:3: 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
>
> Looks like the commit 9487dc84 breaks it when the CONFIG_PCI_IOV switched off.
>
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.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH 12/11] sch_hfsc.c: converter fixups
From: Michal Soltys @ 2011-11-06 1:09 UTC (permalink / raw)
To: kaber; +Cc: davem, netdev
In-Reply-To: <1320460377-8682-9-git-send-email-soltys@ziu.info>
Remove WARN_ON()s added in earlier commit, as the cases they are
supposed to warn about are purely theoretical (would require - aside
from extreme input values - much smaller SM_SHIFT (sm<->m) and larger
PSCHED_SHIFT (dx<->d)).
Signed-off-by: Michal Soltys <soltys@ziu.info>
---
net/sched/sch_hfsc.c | 9 +--------
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/net/sched/sch_hfsc.c b/net/sched/sch_hfsc.c
index 05cecc0..d0cef0f 100644
--- a/net/sched/sch_hfsc.c
+++ b/net/sched/sch_hfsc.c
@@ -407,12 +407,7 @@ cftree_update(struct hfsc_class *cl)
* 2) initialization functions: m2sm, m2ism, d2dx, dx2d
*
* These are used only during [re]setup/reports. Nothing particulary special
- * about those, as user input is limited to 32bit. One remark though:
- *
- * Theoretically, due to rounding up in d2dx() and m2sm(), it's possible that
- * in dx2d() and sm2m() we could overflow as well, but that would require input
- * values near 2^32-1 provided during d2dx() and m2sm(). Just in case, we catch
- * that possibility with WARN_ON().
+ * about those, as user input is limited to 32bit.
*
* 3) rtsc_min
*
@@ -481,7 +476,6 @@ seg_y2x(u64 y, u64 ism)
static u64
m2sm(u32 m)
{
- WARN_ON(m & (1<<31));
return div_u64(((u64)m << SM_SHIFT) + PTPS - 1, PTPS);
}
@@ -510,7 +504,6 @@ m2ism(u32 m)
static u64
d2dx(u32 d)
{
- WARN_ON(d & (1<<31));
return div_u64(((u64)d * PTPS) + USPS - 1, USPS);
}
--
1.7.7.1
^ permalink raw reply related
* [PATCH net v5 4/5] forcedeth: Improve stats counters
From: David Decotigny @ 2011-11-06 0:38 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: David S. Miller, Ian Campbell, Eric Dumazet, Jeff Kirsher,
Jiri Pirko, Joe Perches, Szymon Janc, Mandeep Baines,
David Decotigny
In-Reply-To: <cover.1320539724.git.david.decotigny@google.com>
From: Mandeep Baines <msb@google.com>
Rx byte count was off; instead use the hardware's count. Tx packet
count was counting pre-TSO packets; instead count on-the-wire packets.
Report hardware dropped frame count as rx_fifo_errors.
- The count of transmitted packets reported by the forcedeth driver
reports pre-TSO (TCP Segmentation Offload) packet counts and not the
count of the number of packets sent on the wire. This change fixes
the forcedeth driver to report the correct count. Fixed the code by
copying the count stored in the NIC H/W to the value reported by the
driver.
- Count rx_drop_frame errors as rx_fifo_errors:
We see a lot of rx_drop_frame errors if we disable the rx bottom-halves
for too long. Normally, rx_fifo_errors would be counted in this case.
The rx_drop_frame error count is private to forcedeth and is not
reported by ifconfig or sysfs. The rx_fifo_errors count is currently
unused in the forcedeth driver. It is reported by ifconfig as overruns.
This change reports rx_drop_frame errors as rx_fifo_errors.
Signed-off-by: David Decotigny <david.decotigny@google.com>
---
drivers/net/ethernet/nvidia/forcedeth.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/nvidia/forcedeth.c b/drivers/net/ethernet/nvidia/forcedeth.c
index 2f1eaee..0c10ff7 100644
--- a/drivers/net/ethernet/nvidia/forcedeth.c
+++ b/drivers/net/ethernet/nvidia/forcedeth.c
@@ -1682,6 +1682,7 @@ static void nv_get_hw_stats(struct net_device *dev)
np->estats.tx_pause += readl(base + NvRegTxPause);
np->estats.rx_pause += readl(base + NvRegRxPause);
np->estats.rx_drop_frame += readl(base + NvRegRxDropFrame);
+ np->estats.rx_errors_total += np->estats.rx_drop_frame;
}
if (np->driver_data & DEV_HAS_STATISTICS_V3) {
@@ -1706,11 +1707,14 @@ static struct net_device_stats *nv_get_stats(struct net_device *dev)
nv_get_hw_stats(dev);
/* copy to net_device stats */
+ dev->stats.tx_packets = np->estats.tx_packets;
+ dev->stats.rx_bytes = np->estats.rx_bytes;
dev->stats.tx_bytes = np->estats.tx_bytes;
dev->stats.tx_fifo_errors = np->estats.tx_fifo_errors;
dev->stats.tx_carrier_errors = np->estats.tx_carrier_errors;
dev->stats.rx_crc_errors = np->estats.rx_crc_errors;
dev->stats.rx_over_errors = np->estats.rx_over_errors;
+ dev->stats.rx_fifo_errors = np->estats.rx_drop_frame;
dev->stats.rx_errors = np->estats.rx_errors_total;
dev->stats.tx_errors = np->estats.tx_errors_total;
}
--
1.7.3.1
^ 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