* Re: Route cache performance
From: Simon Kirby @ 2005-08-25 21:22 UTC (permalink / raw)
To: Alexey Kuznetsov; +Cc: Robert Olsson, Eric Dumazet, netdev
In-Reply-To: <20050825200543.GA6612@yakov.inr.ac.ru>
On Fri, Aug 26, 2005 at 12:05:43AM +0400, Alexey Kuznetsov wrote:
> Hello!
>
> > something is holding the refcnt > 0 for almost all of the entries that
> > rt_garbage_collect() walks.
>
> Did you try to look at output of "ip -s -s ro ls ca" ?
> If it is just a refcnt leakage, leaked routes should appear there
> and it is possible to guess, where they leaked.
Hi Alexey,
It appears to be just the DoS traffic I am routing through the box, as
expected, but showing a refcnt for each entry:
cache users 1 age 0sec mtu 1500 advmss 1460 hoplimit 64 iif eth3
I can't find in route.c what would ever decrement refcnt, and it seems to
start being set to 1. It obviously does at some point or else the table
would stay full forever, but when I stop the DoS it falls back down.
What part of the code will decrement the count? I can't see it.
The DoS in this case is set up to be from a spoofed source per packet and
to the address of a remote box behind the box in question. Forwarding is
enabled.
BTW, I hacked a busy loop into juno-z.101f.c to fine rate control and
found that with 2.6.13-rc6, it is unable to keep up with the traffic
starting at about 112 kpps (each packet being a new random source).
Simon-
^ permalink raw reply
* Re: oops in 2.6.13-rc6-git12 in tcp/netfilter routines
From: Sven Schuster @ 2005-08-25 21:02 UTC (permalink / raw)
To: Harald Welte, Alessandro Suardi, netdev,
Linux Kernel Mailing List, netfilter-devel
In-Reply-To: <20050825165550.GC4442@rama.de.gnumonks.org>
[-- Attachment #1: Type: text/plain, Size: 645 bytes --]
Hi Harald,
On Thu, Aug 25, 2005 at 06:55:50PM +0200, Harald Welte told us:
> Is it true that PeerGuardian is a proprietary application? I'm not
> going to debug this problem using a proprietary ip_queue program, sorry.
sorry to jump in here, but I took a quick look at PeerGuardian,
according to
http://methlabs.org/wiki/license_information
it's open source. The source code is available at
http://methlabs.org/projects/peerguardian-linuxosx/
HTH
Sven
--
Linux zion.homelinux.com 2.6.13-rc6-mm2 #3 Thu Aug 25 14:53:55 CEST 2005 i686 athlon i386 GNU/Linux
22:56:18 up 7:40, 1 user, load average: 0.46, 0.14, 0.04
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: 2.6.12 Performance problems
From: Danial Thom @ 2005-08-25 20:45 UTC (permalink / raw)
To: Ben Greear; +Cc: Jesper Juhl, linux-kernel, netdev
In-Reply-To: <430DF7FF.9080502@candelatech.com>
--- Ben Greear <greearb@candelatech.com> wrote:
> Danial Thom wrote:
>
> > The tests I reported where on UP systems.
> Perhaps
> > the default settings are better for this in
> 2.4,
> > since that is what I used, and you used your
> > hacks for both.
>
> My modifications to the kernel are unlikely to
> speed anything
> up, and probably will slow things down ever so
> slightly.
>
> I can try with a UP kernel, but my machine at
> least has a single
> processor. I'm using the SMP kernel to take
> advantage of HT.
>
> > Are you getting drops or overruns (or both)?
> I
> > would assume drops is a decision to drop
> rather
> > than an overrun which is a ring overrun.
> Overruns
> > would imply more about performance than
> tuning,
> > I'd think.
>
> I was seeing lots of NIC errors...in fact, it
> was showing a great many
> more errors than packets sent to it, so I just
> ignored them.
>
> I increased the TxDescriptors and RxDescriptors
> and that helped a little.
>
> Increasing the transmit queue for the NIC to
> 2000 also helped a little.
>
> > I wouldn't think that HT would be appropriate
> for
> > this sort of setup...?
>
> 2.6.11 seems to be faster when running SMP
> kernel on this system.
HT and SMP are not the same animal, are they? My
understanding is that an HT aware scheduler is
likely to make things worse most of the time,
particularly for systems not running a lot of
threads..
> >
> > You're using a dual PCI-X NIC rather than the
> > onboard ports? Supermicro runs their onboard
>
> Of course. Never found a motherboard yet with
> decent built-in
> NICs. The built-ins on this board are tg3 and
> they must be on
> a slow bus, because they cannot go faster than
> about 700Mbps
> (using big pkts).
If its the P8SCI or the same design they are on a
1X PCIE thats shared with the PCI-X. Pretty hokey
stuff. Its also a low-end controller amongst the
broadcom parts.
Danial
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
^ permalink raw reply
* Re: Route cache performance
From: Alexey Kuznetsov @ 2005-08-25 20:05 UTC (permalink / raw)
To: Simon Kirby; +Cc: Robert Olsson, kuznet, Eric Dumazet, netdev
In-Reply-To: <20050825181111.GB14336@netnation.com>
Hello!
> something is holding the refcnt > 0 for almost all of the entries that
> rt_garbage_collect() walks.
Did you try to look at output of "ip -s -s ro ls ca" ?
If it is just a refcnt leakage, leaked routes should appear there
and it is possible to guess, where they leaked.
Alexey
^ permalink raw reply
* Re: Route cache performance
From: Simon Kirby @ 2005-08-25 18:11 UTC (permalink / raw)
To: Robert Olsson, kuznet; +Cc: Eric Dumazet, netdev
In-Reply-To: <20050824000158.GA8137@netnation.com>
[ Alexei / kuznet, I've included you here as I suspect you'll know what's
going on. :) ]
I've been working with 2.6.13-rc6 to try to figure out why it's breaking.
I've added a more rt_cache statistics and flung more DoS traffic at it.
I've determined that when the gc_goal_miss counter is increased, it seems
to be because the refcnt is non-zero in rt_may_expire().
The static "expire" variable reaches 0 easily this case and the rover
variables and loop aren't overflowing or anything -- it's just that
something is holding the refcnt > 0 for almost all of the entries that
rt_garbage_collect() walks. Here are some statistics I recorded:
rt_cache
entries|in_slow|gc_tota|gc_igno|gc_aggr|gc_zero|gc_expi|gc_expi|gc_goa|gc_dst|in_hlis|
| _tot| l| red| essive|_expire| re_no| re_yes|l_miss|overfl| t_srch|
14| 4| 0| 0| 0| 0| 0| 0| 0| 0| 0|
24012| 24003| 15819| 15818| 0| 0| 0| 0| 0| 0| 35182|
131062| 112232| 112229| 110515| 1714| 1703| 10309| 79489| 1711| 1711| 767998|
131062| 14279| 14276| 900| 13376| 13376| 75352| 900| 13376| 13376| 8|
131062| 9542| 9538| 600| 8938| 8938| 50276| 600| 8938| 8938| 5|
131062| 9543| 9539| 600| 8939| 8939| 50278| 600| 8939| 8939| 5|
131062| 9542| 9538| 600| 8938| 8938| 50276| 600| 8938| 8938| 10|
131062| 9542| 9536| 600| 8936| 8936| 50272| 600| 8936| 8936| 6|
131062| 9475| 9472| 600| 8872| 8872| 50144| 600| 8872| 8872| 5|
131062| 9540| 9538| 600| 8938| 8938| 50276| 600| 8938| 8938| 4|
gc_aggressive: Times the "we are in dangerous area" block executes.
gc_zero_expire: Times the loop is broken because expire == 0.
gc_expire_no: Times rt_may_expire() said no.
gc_expire_yes: Times rt_may_expire() said yes.
It seems the code is all the same in 2.4 in rt_may_expire(), so something
outside must have changed. I can't even find anything in route.c that
decrements or zeros the refcnt. Does anybody know why this is happening?
Simon-
On Tue, Aug 23, 2005 at 05:01:58PM -0700, Simon Kirby wrote:
> On Tue, Aug 23, 2005 at 09:56:53PM +0200, Robert Olsson wrote:
>
> > Yes your GC does not work at all in your 2.6 setups...Why?
>
> Good question. :)
>
> > echo 50 > /proc/sys/net/ipv4/route/gc_min_interval_ms
>
> The output looks exactly the same with gc_min_interval_ms set to 50.
>
> If I set it to 0, it does change a little but _still_ overflows:
>
> rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|
> entries| in_hit|in_slow_|gc_total|gc_ignor|gc_goal_|gc_dst_o|in_hlist|
> | | tot| | ed| miss| verflow| _search|
> 3| 3| 1| 1| 1| 0| 0| 0|
> 4| 11| 5| 0| 0| 0| 0| 0|
> 5| 5| 2| 0| 0| 0| 0| 0|
> 23615| 1| 24002| 15812| 0| 0| 0| 11470|
> 68692| 0| 46780| 46777| 0| 4687| 0| 4492|
> 86046| 0| 18763| 18754| 0| 18754| 0| 119|
> 94884| 0| 9540| 9538| 0| 9538| 0| 47|
> 104901| 0| 10819| 10817| 0| 10817| 0| 61|
> 114919| 0| 10817| 10818| 0| 10818| 0| 68|
> 127424| 0| 13512| 13505| 0| 13505| 0| 74|
> 131062| 0| 15113| 15106| 0| 15106| 10368| 28|
> 131062| 0| 12503| 12482| 0| 12482| 11582| 9|
> 131062| 0| 8146| 8130| 0| 8130| 7530| 5|
> 131062| 0| 8204| 8194| 0| 8194| 7594| 2|
> 131062| 0| 8132| 8131| 0| 8131| 7531| 5|
> 131062| 0| 8196| 8195| 0| 8195| 7595| 4|
> 131062| 0| 8130| 8129| 0| 8129| 7529| 8|
^ permalink raw reply
* Re: oops in 2.6.13-rc6-git12 in tcp/netfilter routines
From: Alessandro Suardi @ 2005-08-25 17:26 UTC (permalink / raw)
To: Harald Welte, Alessandro Suardi, netdev,
Linux Kernel Mailing List, netfilter-devel
In-Reply-To: <20050825165550.GC4442@rama.de.gnumonks.org>
On 8/25/05, Harald Welte <laforge@netfilter.org> wrote:
> On Thu, Aug 25, 2005 at 03:39:02PM +0200, Alessandro Suardi wrote:
> > Howdy, and excuse me for crossposting - feel free to zap CC to
> > unrelated, if any, mailing lists.
> >
> > just gave PeerGuardian a spin on my eDonkey home box and
> > said box didn't last half a day before oopsing in netlink/nf/tcp
> > related routines (or so it seems to my untrained eye).
>
> Yes, it indeed could be that there is some fishy interaction between the
> tcp stack and ip_queue causing the oops.
>
> > K7800, 256MB RAM, uptodate FC3 running 2.6.13-rc6-git12,
> > doing nothing but running MetaMachine's eDonkey 1.4.3 QT gui.
> > PeerGuardian is the 1.5 beta version available from methlabs.org.
>
> Is it true that PeerGuardian is a proprietary application? I'm not
> going to debug this problem using a proprietary ip_queue program, sorry.
I'm not sure I understand the issue; I built PG from these sources:
http://prdownloads.sourceforge.net/peerguardian/pglinux-1.5beta.tar.gz?download
and I had to install the iptables-devel FC3 rpm to build. The PG
sources seem to be licensed under GPLv2. But maybe you're
referring to the fact that whatever PG does, it doesn't show up
as output from 'iptables -L' ?
> If you can produce a testcase with open source userspace ip_queue code,
> I could look into reproducing the problem locally and debugging the
> problem more thoroughly.
So far the box has been running for over four hours, I'll configure
my laptop as a netdump server hoping it might capture something
if the ed2k box crashes again later. I'm afraid I won't be able to set
up a real testcase (and btw, edonkey v1.4.3 from MetaMachine is
actually a proprietary program, though entirely in userspace).
> While it definitely is a kernel bug (whatever userspace sends should not
> crash the kernel), it might be something that specifically [only]
> PeerGuardian does to the packet. Something that ip_queue doesn't check
> (but should check) on packet reinjection and therefore upsets the TCP stack.
>
> Also helpful would be the output of an "strace -f -x -s65535 -e
> trace=sendmsg" on the PeerGuardian (daemon?) process.
>
>
> > [<c0103714>] die+0xe4/0x170
> > [<c010381f>] do_trap+0x7f/0xc0
> > [<c0103b33>] do_invalid_op+0xa3/0xb0
> > [<c0102faf>] error_code+0x4f/0x54
> > [<c02eb05b>] kfree_skbmem+0xb/0x20
> > [<c02eb0cf>] __kfree_skb+0x5f/0xf0
>
> ok, so something down the chain from kfree_skb() results in an invalid
> operation? looks more like some compiler problem, bad memory or memory
> corruption to me. Try to reproduce the problem without PG.
compiler is fc3's latest - gcc-3.4.4-2.fc3. I might have a go at
memtest86 in the next weeks if more symptoms point at
possible bad RAM.
> > [<c031304a>] tcp_clean_rtx_queue+0x16a/0x470
> > [<c0313746>] tcp_ack+0xf6/0x360
> > [<c0315d57>] tcp_rcv_established+0x277/0x7a0
> > [<c031eba0>] tcp_v4_do_rcv+0xf0/0x110
> > [<c031f2a0>] tcp_v4_rcv+0x6e0/0x820
> > [<c0305594>] ip_local_deliver_finish+0x84/0x160
>
> so something in the tcp stack ends up doing tcp_clean_rtx_queue()
>
> > [<c02fbe4a>] nf_reinject+0x13a/0x1c0
> > [<c033f0d8>] ipq_issue_verdict+0x28/0x40
> > [<c033f968>] ipq_set_verdict+0x48/0x70
>
> ip_queue reinjects a packet via nf_reinject()
>
> > [<c033fa79>] ipq_receive_peer+0x39/0x50
> > [<c033fc72>] ipq_receive_sk+0x172/0x190
>
> ip_queue receives and ipq verdict msg packet from netlink
>
> > [<c02fffa5>] netlink_data_ready+0x35/0x60
> > [<c02ff4a4>] netlink_sendskb+0x24/0x60
> > [<c02ff657>] netlink_unicast+0x127/0x160
> > [<c02ffcc4>] netlink_sendmsg+0x204/0x2b0
> > [<c02e6dc0>] sock_sendmsg+0xb0/0xe0
> > [<c02e83f4>] sys_sendmsg+0x134/0x240
> > [<c02e88e4>] sys_socketcall+0x224/0x230
> > [<c0102d3b>] sysenter_past_esp+0x54/0x75
>
> process sendmsg()s on the netlink socket.
Thanks,
--alessandro
"Not every smile means I'm laughing inside"
(Wallflowers - "From The Bottom Of My Heart")
^ permalink raw reply
* Re: oops in 2.6.13-rc6-git12 in tcp/netfilter routines
From: Harald Welte @ 2005-08-25 16:55 UTC (permalink / raw)
To: Alessandro Suardi; +Cc: netdev, Linux Kernel Mailing List, netfilter-devel
In-Reply-To: <5a4c581d05082506395fa984ae@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3262 bytes --]
On Thu, Aug 25, 2005 at 03:39:02PM +0200, Alessandro Suardi wrote:
> Howdy, and excuse me for crossposting - feel free to zap CC to
> unrelated, if any, mailing lists.
>
> just gave PeerGuardian a spin on my eDonkey home box and
> said box didn't last half a day before oopsing in netlink/nf/tcp
> related routines (or so it seems to my untrained eye).
Yes, it indeed could be that there is some fishy interaction between the
tcp stack and ip_queue causing the oops.
> K7800, 256MB RAM, uptodate FC3 running 2.6.13-rc6-git12,
> doing nothing but running MetaMachine's eDonkey 1.4.3 QT gui.
> PeerGuardian is the 1.5 beta version available from methlabs.org.
Is it true that PeerGuardian is a proprietary application? I'm not
going to debug this problem using a proprietary ip_queue program, sorry.
If you can produce a testcase with open source userspace ip_queue code,
I could look into reproducing the problem locally and debugging the
problem more thoroughly.
While it definitely is a kernel bug (whatever userspace sends should not
crash the kernel), it might be something that specifically [only]
PeerGuardian does to the packet. Something that ip_queue doesn't check
(but should check) on packet reinjection and therefore upsets the TCP stack.
Also helpful would be the output of an "strace -f -x -s65535 -e
trace=sendmsg" on the PeerGuardian (daemon?) process.
> [<c0103714>] die+0xe4/0x170
> [<c010381f>] do_trap+0x7f/0xc0
> [<c0103b33>] do_invalid_op+0xa3/0xb0
> [<c0102faf>] error_code+0x4f/0x54
> [<c02eb05b>] kfree_skbmem+0xb/0x20
> [<c02eb0cf>] __kfree_skb+0x5f/0xf0
ok, so something down the chain from kfree_skb() results in an invalid
operation? looks more like some compiler problem, bad memory or memory
corruption to me. Try to reproduce the problem without PG.
> [<c031304a>] tcp_clean_rtx_queue+0x16a/0x470
> [<c0313746>] tcp_ack+0xf6/0x360
> [<c0315d57>] tcp_rcv_established+0x277/0x7a0
> [<c031eba0>] tcp_v4_do_rcv+0xf0/0x110
> [<c031f2a0>] tcp_v4_rcv+0x6e0/0x820
> [<c0305594>] ip_local_deliver_finish+0x84/0x160
so something in the tcp stack ends up doing tcp_clean_rtx_queue()
> [<c02fbe4a>] nf_reinject+0x13a/0x1c0
> [<c033f0d8>] ipq_issue_verdict+0x28/0x40
> [<c033f968>] ipq_set_verdict+0x48/0x70
ip_queue reinjects a packet via nf_reinject()
> [<c033fa79>] ipq_receive_peer+0x39/0x50
> [<c033fc72>] ipq_receive_sk+0x172/0x190
ip_queue receives and ipq verdict msg packet from netlink
> [<c02fffa5>] netlink_data_ready+0x35/0x60
> [<c02ff4a4>] netlink_sendskb+0x24/0x60
> [<c02ff657>] netlink_unicast+0x127/0x160
> [<c02ffcc4>] netlink_sendmsg+0x204/0x2b0
> [<c02e6dc0>] sock_sendmsg+0xb0/0xe0
> [<c02e83f4>] sys_sendmsg+0x134/0x240
> [<c02e88e4>] sys_socketcall+0x224/0x230
> [<c0102d3b>] sysenter_past_esp+0x54/0x75
process sendmsg()s on the netlink socket.
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: 2.6.12 Performance problems
From: Ben Greear @ 2005-08-25 16:55 UTC (permalink / raw)
To: danial_thom; +Cc: Jesper Juhl, linux-kernel, netdev
In-Reply-To: <20050825142647.70995.qmail@web33314.mail.mud.yahoo.com>
Danial Thom wrote:
> The tests I reported where on UP systems. Perhaps
> the default settings are better for this in 2.4,
> since that is what I used, and you used your
> hacks for both.
My modifications to the kernel are unlikely to speed anything
up, and probably will slow things down ever so slightly.
I can try with a UP kernel, but my machine at least has a single
processor. I'm using the SMP kernel to take advantage of HT.
> Are you getting drops or overruns (or both)? I
> would assume drops is a decision to drop rather
> than an overrun which is a ring overrun. Overruns
> would imply more about performance than tuning,
> I'd think.
I was seeing lots of NIC errors...in fact, it was showing a great many
more errors than packets sent to it, so I just ignored them.
I increased the TxDescriptors and RxDescriptors and that helped a little.
Increasing the transmit queue for the NIC to 2000 also helped a little.
> I wouldn't think that HT would be appropriate for
> this sort of setup...?
2.6.11 seems to be faster when running SMP kernel on this system.
>
> You're using a dual PCI-X NIC rather than the
> onboard ports? Supermicro runs their onboard
Of course. Never found a motherboard yet with decent built-in
NICs. The built-ins on this board are tg3 and they must be on
a slow bus, because they cannot go faster than about 700Mbps
(using big pkts).
I'll benchmark things again when 2.6.13 comes out and try to
get some more detailed numbers...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [OT] legal status of re-engineering (was Re: atheros driver - desc)
From: Harald Welte @ 2005-08-25 16:36 UTC (permalink / raw)
To: Kalle Valo; +Cc: kernel-mentors, netdev, Jeff Garzik
In-Reply-To: <20050807150134.GB4855@rama.de.gnumonks.org>
[-- Attachment #1.1: Type: text/plain, Size: 2228 bytes --]
Sorry for again posting something OT, but I think the result of this
discussion will in the end provide valuable input to a lot of driver
authors.
On Sun, Aug 07, 2005 at 05:01:34PM +0200, Harald Welte wrote:
> On Sun, Aug 07, 2005 at 10:32:07AM +0300, Kalle Valo wrote:
> > Harald Welte <laforge@gnumonks.org> writes:
> >
> > > I don't want to turn this list into a list of legal discussion, but
> > > since I'm heavily dealing with exactly those issues during my
> > > gpl-violations.org efforts, I thought I share some of the facts.
> >
> > Thanks for your answer, it cleared up things. I also don't want to
> > discuss legal things here, we can discuss it more privately. But I'll
> > just ask one more question in public:
> >
> > > So in general, at least if you're doing that kind of work within the EU,
> > > I wouldn't be worried all that much.
> >
> > That's good news. But what about inclusion to the official Linux
> > kernel? Can a driver reverse-engineered in EU be included to the
> > kernel? (Big part of Linux is developed in US, I guess.)
>
> I will consult my legal counsel about this.
Ok, as it seems the matter has not yet been investigated thoroughly
enough from a legal point of view. The German institute for law and
opensource software (http://www.ifross.org/) is interested in writing up
and publishing a legal article on that subject, but that will certainly
take some time for legal research, etc. I'll be advising them on
technical matters and get back to you as soon there is some result.
The analysis will be based on the EU copyright directive and should
therefore be more-or-less valid for all EU member states.
The US is totally different. As indicated before my holidays (just got
back yesterday), I'll contact Eben Moglen about this, but first want to
write up some explanations, questions, ... to give him the correct
input.
--
- Harald Welte <laforge@gnumonks.org> http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 154 bytes --]
_______________________________________________
Kernel-mentors mailing list
Kernel-mentors@selenic.com
http://selenic.com/mailman/listinfo/kernel-mentors
^ permalink raw reply
* Re: 2.6.12 Performance problems
From: Danial Thom @ 2005-08-25 14:26 UTC (permalink / raw)
To: Ben Greear; +Cc: Jesper Juhl, linux-kernel, netdev
In-Reply-To: <430D668A.6030306@candelatech.com>
--- Ben Greear <greearb@candelatech.com> wrote:
> Danial Thom wrote:
> >
> > --- Ben Greear <greearb@candelatech.com>
> wrote:
> >
> >
> >>Danial Thom wrote:
> >>
> >>
> >>>I think the concensus is that 2.6 has made
> >>
> >>trade
> >>
> >>>offs that lower raw throughput, which is
> what
> >>
> >>a
> >>
> >>>networking device needs. So as a router or
> >>>network appliance, 2.6 seems less suitable.
> A
> >>
> >>raw
> >>
> >>>bridging test on a 2.0Ghz operton system:
> >>>
> >>>FreeBSD 4.9: Drops no packets at 900K pps
> >>>Linux 2.4.24: Starts dropping packets at
> 350K
> >>
> >>pps
> >>
> >>>Linux 2.6.12: Starts dropping packets at
> 100K
> >>
> >>pps
> >>
> >>I ran some quick tests using kernel 2.6.11,
> 1ms
> >>tick (HZ=1000), SMP kernel.
> >>Hardware is P-IV 3.0Ghz + HT on a new
> >>SuperMicro motherboard with 64/133Mhz
> >>PCI-X bus. NIC is dual Intel pro/1000.
> Kernel
> >>is close to stock 2.6.11.
> >>
> >>I used brctl to create a bridge with the two
> >>GigE adapters in it and
> >>used pktgen to stream traffic through it
> >>(250kpps in one direction, 1kpps in
> >>the other.)
> >>
> >>I see a reasonable amount of drops at 250kpps
> >>(60 byte packets):
> >>about 60,000,000 packets received, 20,700
> >>dropped.
>
> I get slightly worse performance on this system
> when running RH9
> with kernel 2.4.29 (my hacks, HZ=1000, SMP).
> Tried increasing
> e1000 descriptors to 2048 tx and rx, but that
> didn't help, or at least
> not much.
>
> Will try some other tunings, but I doubt it
> will affect performance
> enough to come close to the discrepency that
> you show between 2.4
> and 2.6 kernels...
>
> I tried copying a 500MB CDROM to HD on my RH9
> system, and only 6kpps
> of the 250kpps get through the bridge...btw.
The tests I reported where on UP systems. Perhaps
the default settings are better for this in 2.4,
since that is what I used, and you used your
hacks for both.
Are you getting drops or overruns (or both)? I
would assume drops is a decision to drop rather
than an overrun which is a ring overrun. Overruns
would imply more about performance than tuning,
I'd think.
I wouldn't think that HT would be appropriate for
this sort of setup...?
You're using a dual PCI-X NIC rather than the
onboard ports? Supermicro runs their onboard
controllers at 32bit/33mhz for some mindless
reason.
Danial
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* oops in 2.6.13-rc6-git12 in tcp/netfilter routines
From: Alessandro Suardi @ 2005-08-25 13:39 UTC (permalink / raw)
To: netdev, Linux Kernel Mailing List, netfilter-devel
Howdy, and excuse me for crossposting - feel free to zap CC to
unrelated, if any, mailing lists.
just gave PeerGuardian a spin on my eDonkey home box and
said box didn't last half a day before oopsing in netlink/nf/tcp
related routines (or so it seems to my untrained eye).
K7800, 256MB RAM, uptodate FC3 running 2.6.13-rc6-git12,
doing nothing but running MetaMachine's eDonkey 1.4.3 QT gui.
PeerGuardian is the 1.5 beta version available from methlabs.org.
Stack is hand-copied from the dead box's console.
[<c0103714>] die+0xe4/0x170
[<c010381f>] do_trap+0x7f/0xc0
[<c0103b33>] do_invalid_op+0xa3/0xb0
[<c0102faf>] error_code+0x4f/0x54
[<c02eb05b>] kfree_skbmem+0xb/0x20
[<c02eb0cf>] __kfree_skb+0x5f/0xf0
[<c031304a>] tcp_clean_rtx_queue+0x16a/0x470
[<c0313746>] tcp_ack+0xf6/0x360
[<c0315d57>] tcp_rcv_established+0x277/0x7a0
[<c031eba0>] tcp_v4_do_rcv+0xf0/0x110
[<c031f2a0>] tcp_v4_rcv+0x6e0/0x820
[<c0305594>] ip_local_deliver_finish+0x84/0x160
[<c02fbe4a>] nf_reinject+0x13a/0x1c0
[<c033f0d8>] ipq_issue_verdict+0x28/0x40
[<c033f968>] ipq_set_verdict+0x48/0x70
[<c033fa79>] ipq_receive_peer+0x39/0x50
[<c033fc72>] ipq_receive_sk+0x172/0x190
[<c02fffa5>] netlink_data_ready+0x35/0x60
[<c02ff4a4>] netlink_sendskb+0x24/0x60
[<c02ff657>] netlink_unicast+0x127/0x160
[<c02ffcc4>] netlink_sendmsg+0x204/0x2b0
[<c02e6dc0>] sock_sendmsg+0xb0/0xe0
[<c02e83f4>] sys_sendmsg+0x134/0x240
[<c02e88e4>] sys_socketcall+0x224/0x230
[<c0102d3b>] sysenter_past_esp+0x54/0x75
Code: 8b 41 0c 85 c0 75 1b 8b 86 94 00 00 00 e8 9e 37 e5 ff 5b 5e c9
c3 89 d0 e8 43 46 e5 ff 8d 76 00 eb d2 89 f0 e8 f7 fe ff ff eb dc <0f>
0b 54 01 16 d2 36 c0 eb b4 8d 74 26 00 8d bc 27 00 00 00 00
<0>Kernel panic - not syncing: Fatal exception in interrupt
If there's need for further info I'd be happy to provide it. For now
the box is rebooted into the same kernel and running the same
PG/eD2k programs, if the issue reproduces I'll follow up on my
own message.
Thanks in advance, ciao,
--alessandro
"Not every smile means I'm laughing inside"
(Wallflowers - "From The Bottom Of My Heart")
^ permalink raw reply
* [patch] ipw2200: remove trap and unused stuff
From: Pavel Machek @ 2005-08-25 11:05 UTC (permalink / raw)
To: Jeff Garzik, Netdev list, kernel list, James P. Ketrenos, jbenc,
jbo
This removes one trap for a programmer, few unused macros, and one
unused struct. Please apply,
Signed-off-by: Pavel Machek <pavel@suse.cz>
--- clean-mm/drivers/net/wireless/ipw2200.c 2005-08-24 20:25:09.000000000 +0200
+++ linux-mm/drivers/net/wireless/ipw2200.c 2005-08-25 12:50:19.000000000 +0200
@@ -4485,7 +4485,7 @@
IPW_DEBUG_INFO("RATE MASK: 0x%08X\n", priv->rates_mask);
}
#else
-#define ipw_debug_config(x) do {} while (0);
+#define ipw_debug_config(x) do {} while (0)
#endif
static inline void ipw_set_fixed_rate(struct ipw_priv *priv,
--- clean-mm/drivers/net/wireless/ipw2200.h 2005-08-24 20:25:09.000000000 +0200
+++ linux-mm/drivers/net/wireless/ipw2200.h 2005-08-25 12:42:30.000000000 +0200
@@ -95,8 +75,6 @@
};
-#define IPW_NORMAL 0
-#define IPW_NOWAIT 0
#define IPW_WAIT (1<<0)
#define IPW_QUIET (1<<1)
#define IPW_ROAMING (1<<2)
@@ -202,7 +180,7 @@
/* even if MAC WEP set (allows pre-encrypt) */
#define DCT_FLAG_NO_WEP 0x20
-#define IPW_
+
/* overwrite TSF field */
#define DCT_FLAG_TSF_REQD 0x40
@@ -535,12 +513,6 @@
u16 status;
} __attribute__ ((packed));
-struct temperature
-{
- s32 measured;
- s32 active;
-} __attribute__ ((packed));
-
struct notif_calibration {
u8 data[104];
} __attribute__ ((packed));
--
if you have sharp zaurus hardware you don't need... you know my address
^ permalink raw reply
* [patch] ipw2200: remove support for obsolete kernels
From: Pavel Machek @ 2005-08-25 11:04 UTC (permalink / raw)
To: Jeff Garzik, Netdev list, kernel list, James P. Ketrenos, jbenc,
jbo
This removes support for old (and non-mainline) kernels from
ipw2200. Please apply,
Signed-off-by: Pavel Machek <pavel@suse.cz>
--- clean-mm/drivers/net/wireless/ipw2200.c 2005-08-24 20:25:09.000000000 +0200
+++ linux-mm/drivers/net/wireless/ipw2200.c 2005-08-25 12:50:19.000000000 +0200
@@ -6617,11 +6617,7 @@
{
int ret = 0;
-#ifdef CONFIG_SOFTWARE_SUSPEND2
- priv->workqueue = create_workqueue(DRV_NAME, 0);
-#else
priv->workqueue = create_workqueue(DRV_NAME);
-#endif
init_waitqueue_head(&priv->wait_command_queue);
INIT_WORK(&priv->adhoc_check, ipw_adhoc_check, priv);
@@ -7242,11 +7238,7 @@
/* Remove the PRESENT state of the device */
netif_device_detach(dev);
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,10)
- pci_save_state(pdev, priv->pm_state);
-#else
pci_save_state(pdev);
-#endif
pci_disable_device(pdev);
pci_set_power_state(pdev, pci_choose_state(pdev, state));
--- clean-mm/drivers/net/wireless/ipw2200.h 2005-08-24 20:25:09.000000000 +0200
+++ linux-mm/drivers/net/wireless/ipw2200.h 2005-08-25 12:42:30.000000000 +0200
@@ -55,26 +55,6 @@
#include <linux/workqueue.h>
-#ifndef IRQ_NONE
-typedef void irqreturn_t;
-#define IRQ_NONE
-#define IRQ_HANDLED
-#define IRQ_RETVAL(x)
-#endif
-
-#if ( LINUX_VERSION_CODE < KERNEL_VERSION(2,6,9) )
-#define __iomem
-#endif
-
-#if ( LINUX_VERSION_CODE < KERNEL_VERSION(2,6,5) )
-#define pci_dma_sync_single_for_cpu pci_dma_sync_single
-#define pci_dma_sync_single_for_device pci_dma_sync_single
-#endif
-
-#ifndef HAVE_FREE_NETDEV
-#define free_netdev(x) kfree(x)
-#endif
-
/* Authentication and Association States */
enum connection_manager_assoc_states
{
--
if you have sharp zaurus hardware you don't need... you know my address
^ permalink raw reply
* Re: 2.6.12 Performance problems
From: Ben Greear @ 2005-08-25 6:34 UTC (permalink / raw)
To: danial_thom; +Cc: Jesper Juhl, linux-kernel, netdev
In-Reply-To: <20050825060843.15874.qmail@web33311.mail.mud.yahoo.com>
Danial Thom wrote:
>
> --- Ben Greear <greearb@candelatech.com> wrote:
>
>
>>Danial Thom wrote:
>>
>>
>>>I think the concensus is that 2.6 has made
>>
>>trade
>>
>>>offs that lower raw throughput, which is what
>>
>>a
>>
>>>networking device needs. So as a router or
>>>network appliance, 2.6 seems less suitable. A
>>
>>raw
>>
>>>bridging test on a 2.0Ghz operton system:
>>>
>>>FreeBSD 4.9: Drops no packets at 900K pps
>>>Linux 2.4.24: Starts dropping packets at 350K
>>
>>pps
>>
>>>Linux 2.6.12: Starts dropping packets at 100K
>>
>>pps
>>
>>I ran some quick tests using kernel 2.6.11, 1ms
>>tick (HZ=1000), SMP kernel.
>>Hardware is P-IV 3.0Ghz + HT on a new
>>SuperMicro motherboard with 64/133Mhz
>>PCI-X bus. NIC is dual Intel pro/1000. Kernel
>>is close to stock 2.6.11.
>>
>>I used brctl to create a bridge with the two
>>GigE adapters in it and
>>used pktgen to stream traffic through it
>>(250kpps in one direction, 1kpps in
>>the other.)
>>
>>I see a reasonable amount of drops at 250kpps
>>(60 byte packets):
>>about 60,000,000 packets received, 20,700
>>dropped.
I get slightly worse performance on this system when running RH9
with kernel 2.4.29 (my hacks, HZ=1000, SMP). Tried increasing
e1000 descriptors to 2048 tx and rx, but that didn't help, or at least
not much.
Will try some other tunings, but I doubt it will affect performance
enough to come close to the discrepency that you show between 2.4
and 2.6 kernels...
I tried copying a 500MB CDROM to HD on my RH9 system, and only 6kpps
of the 250kpps get through the bridge...btw.
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: 2.6.12 Performance problems
From: Ben Greear @ 2005-08-25 6:15 UTC (permalink / raw)
To: danial_thom; +Cc: Jesper Juhl, linux-kernel, netdev
In-Reply-To: <20050825060843.15874.qmail@web33311.mail.mud.yahoo.com>
Danial Thom wrote:
>
> --- Ben Greear <greearb@candelatech.com> wrote:
>
>
>>Danial Thom wrote:
>>
>>
>>>I think the concensus is that 2.6 has made
>>
>>trade
>>
>>>offs that lower raw throughput, which is what
>>
>>a
>>
>>>networking device needs. So as a router or
>>>network appliance, 2.6 seems less suitable. A
>>
>>raw
>>
>>>bridging test on a 2.0Ghz operton system:
>>>
>>>FreeBSD 4.9: Drops no packets at 900K pps
>>>Linux 2.4.24: Starts dropping packets at 350K
>>
>>pps
>>
>>>Linux 2.6.12: Starts dropping packets at 100K
>>
>>pps
>>
>>I ran some quick tests using kernel 2.6.11, 1ms
>>tick (HZ=1000), SMP kernel.
>>Hardware is P-IV 3.0Ghz + HT on a new
>>SuperMicro motherboard with 64/133Mhz
>>PCI-X bus. NIC is dual Intel pro/1000. Kernel
>>is close to stock 2.6.11.
> What GigE adapters did you use? Clearly every
> driver is going to be different. My experience is
> that a 3.4Ghz P4 is about the performance of a
> 2.0Ghz Opteron. I have to try your tuning script
> tomorrow.
Intel pro/1000, as I mentioned. I haven't tried any other
NIC that comes close in performance to the e1000.
> If your test is still set up, try compiling
> something large while doing the test. The drops
> go through the roof in my tests.
Installing RH9 on the box now to try some tests...
Disk access always robs networking, in my experience, so
I am not supprised you see bad ntwk performance while
compiling.
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: 2.6.12 Performance problems
From: Danial Thom @ 2005-08-25 6:08 UTC (permalink / raw)
To: Ben Greear; +Cc: Jesper Juhl, linux-kernel, netdev
In-Reply-To: <430D4E6D.1090200@candelatech.com>
--- Ben Greear <greearb@candelatech.com> wrote:
> Danial Thom wrote:
>
> > I think the concensus is that 2.6 has made
> trade
> > offs that lower raw throughput, which is what
> a
> > networking device needs. So as a router or
> > network appliance, 2.6 seems less suitable. A
> raw
> > bridging test on a 2.0Ghz operton system:
> >
> > FreeBSD 4.9: Drops no packets at 900K pps
> > Linux 2.4.24: Starts dropping packets at 350K
> pps
> > Linux 2.6.12: Starts dropping packets at 100K
> pps
>
> I ran some quick tests using kernel 2.6.11, 1ms
> tick (HZ=1000), SMP kernel.
> Hardware is P-IV 3.0Ghz + HT on a new
> SuperMicro motherboard with 64/133Mhz
> PCI-X bus. NIC is dual Intel pro/1000. Kernel
> is close to stock 2.6.11.
>
> I used brctl to create a bridge with the two
> GigE adapters in it and
> used pktgen to stream traffic through it
> (250kpps in one direction, 1kpps in
> the other.)
>
> I see a reasonable amount of drops at 250kpps
> (60 byte packets):
> about 60,000,000 packets received, 20,700
> dropped.
>
> Interestingly, the system is about 60% idle
> according to top,
> and still dropping pkts, so it would seem that
> the system could
> be better utilized!
>
> Ben
>
What GigE adapters did you use? Clearly every
driver is going to be different. My experience is
that a 3.4Ghz P4 is about the performance of a
2.0Ghz Opteron. I have to try your tuning script
tomorrow.
If your test is still set up, try compiling
something large while doing the test. The drops
go through the roof in my tests.
Danial
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
^ permalink raw reply
* Re: 2.6.12 Performance problems
From: Ben Greear @ 2005-08-25 4:51 UTC (permalink / raw)
To: danial_thom; +Cc: Jesper Juhl, linux-kernel, netdev
In-Reply-To: <20050824172631.11829.qmail@web33309.mail.mud.yahoo.com>
Danial Thom wrote:
> I think the concensus is that 2.6 has made trade
> offs that lower raw throughput, which is what a
> networking device needs. So as a router or
> network appliance, 2.6 seems less suitable. A raw
> bridging test on a 2.0Ghz operton system:
>
> FreeBSD 4.9: Drops no packets at 900K pps
> Linux 2.4.24: Starts dropping packets at 350K pps
> Linux 2.6.12: Starts dropping packets at 100K pps
I ran some quick tests using kernel 2.6.11, 1ms tick (HZ=1000), SMP kernel.
Hardware is P-IV 3.0Ghz + HT on a new SuperMicro motherboard with 64/133Mhz
PCI-X bus. NIC is dual Intel pro/1000. Kernel is close to stock 2.6.11.
I used brctl to create a bridge with the two GigE adapters in it and
used pktgen to stream traffic through it (250kpps in one direction, 1kpps in
the other.)
I see a reasonable amount of drops at 250kpps (60 byte packets):
about 60,000,000 packets received, 20,700 dropped.
Interestingly, the system is about 60% idle according to top,
and still dropping pkts, so it would seem that the system could
be better utilized!
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 3/3] Cleanup direct calls into IP stack
From: David S. Miller @ 2005-08-24 18:39 UTC (permalink / raw)
To: ralf; +Cc: netdev, linux-hams
In-Reply-To: <20050824171712.GB8367@linux-mips.org>
All 3 patches queued up for 2.6.14, thanks a lot Ralf.
^ permalink raw reply
* [PATCH 3/3] Cleanup direct calls into IP stack
From: Ralf Baechle DL5RB @ 2005-08-24 17:17 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-hams
With ip_rcv nowhere outside the IP stack being used anymore it's
EXPORT_SYMBOL is not needed any longer either.
Signed-off-by: Ralf Baechle DL5RB <ralf@linux-mips.org>
net/ipv4/ip_input.c | 1 -
1 files changed, 1 deletion(-)
Index: linux-cvs/net/ipv4/ip_input.c
===================================================================
--- linux-cvs.orig/net/ipv4/ip_input.c
+++ linux-cvs/net/ipv4/ip_input.c
@@ -428,5 +428,4 @@ out:
return NET_RX_DROP;
}
-EXPORT_SYMBOL(ip_rcv);
EXPORT_SYMBOL(ip_statistics);
^ permalink raw reply
* [PATCH 2/3] Cleanup direct calls into IP stack
From: Ralf Baechle DL5RB @ 2005-08-24 17:16 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-hams
All these are claiming to include <net/ip.h> to get ip_rcv() but in
fact don't need the header at all, so away with the inclusion.
Signed-off-by: Ralf Baechle DL5RB <ralf@linux-mips.org>
net/ax25/ax25_ds_in.c | 1 -
net/ax25/ax25_std_in.c | 1 -
net/netrom/nr_in.c | 1 -
net/rose/rose_in.c | 1 -
4 files changed, 4 deletions(-)
Index: linux-cvs/net/ax25/ax25_ds_in.c
===================================================================
--- linux-cvs.orig/net/ax25/ax25_ds_in.c
+++ linux-cvs/net/ax25/ax25_ds_in.c
@@ -22,7 +22,6 @@
#include <linux/netdevice.h>
#include <linux/skbuff.h>
#include <net/sock.h>
-#include <net/ip.h> /* For ip_rcv */
#include <net/tcp.h>
#include <asm/uaccess.h>
#include <asm/system.h>
Index: linux-cvs/net/ax25/ax25_std_in.c
===================================================================
--- linux-cvs.orig/net/ax25/ax25_std_in.c
+++ linux-cvs/net/ax25/ax25_std_in.c
@@ -29,7 +29,6 @@
#include <linux/netdevice.h>
#include <linux/skbuff.h>
#include <net/sock.h>
-#include <net/ip.h> /* For ip_rcv */
#include <net/tcp.h>
#include <asm/uaccess.h>
#include <asm/system.h>
Index: linux-cvs/net/netrom/nr_in.c
===================================================================
--- linux-cvs.orig/net/netrom/nr_in.c
+++ linux-cvs/net/netrom/nr_in.c
@@ -23,7 +23,6 @@
#include <linux/skbuff.h>
#include <net/sock.h>
#include <net/tcp.h>
-#include <net/ip.h> /* For ip_rcv */
#include <asm/uaccess.h>
#include <asm/system.h>
#include <linux/fcntl.h>
Index: linux-cvs/net/rose/rose_in.c
===================================================================
--- linux-cvs.orig/net/rose/rose_in.c
+++ linux-cvs/net/rose/rose_in.c
@@ -26,7 +26,6 @@
#include <linux/netdevice.h>
#include <linux/skbuff.h>
#include <net/sock.h>
-#include <net/ip.h> /* For ip_rcv */
#include <net/tcp.h>
#include <asm/system.h>
#include <linux/fcntl.h>
^ permalink raw reply
* [PATCH 1/2] Cleanup direct calls into IP stack
From: Ralf Baechle @ 2005-08-24 17:15 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-hams
Get rid of the calls to ip_rcv and arp_rcv which were laying violations
anyway. With those being replaced by netif_rx less parts of AX.25 and
relatives depend on INET support actually being enabled. This also
will make PF_PACKET sockets work for IP and ARP packets receiver over
AX.25 and for IP packets over NET/ROM.
Signed-off-by: Ralf Baechle DL5RB <ralf@linux-mips.org>
net/ax25/ax25_in.c | 13 +++----------
net/netrom/af_netrom.c | 5 ++---
net/netrom/nr_dev.c | 5 ++---
3 files changed, 7 insertions(+), 16 deletions(-)
Index: linux-cvs/net/ax25/ax25_in.c
===================================================================
--- linux-cvs.orig/net/ax25/ax25_in.c
+++ linux-cvs/net/ax25/ax25_in.c
@@ -9,7 +9,6 @@
* Copyright (C) Joerg Reuter DL1BKE (jreuter@yaina.de)
* Copyright (C) Hans-Joachim Hetscher DD8NE (dd8ne@bnv-bamberg.de)
*/
-#include <linux/config.h>
#include <linux/errno.h>
#include <linux/types.h>
#include <linux/socket.h>
@@ -26,9 +25,7 @@
#include <linux/skbuff.h>
#include <linux/netfilter.h>
#include <net/sock.h>
-#include <net/ip.h> /* For ip_rcv */
#include <net/tcp.h>
-#include <net/arp.h> /* For arp_rcv */
#include <asm/uaccess.h>
#include <asm/system.h>
#include <linux/fcntl.h>
@@ -114,7 +111,6 @@ int ax25_rx_iframe(ax25_cb *ax25, struct
pid = *skb->data;
-#ifdef CONFIG_INET
if (pid == AX25_P_IP) {
/* working around a TCP bug to keep additional listeners
* happy. TCP re-uses the buffer and destroys the original
@@ -132,10 +128,9 @@ int ax25_rx_iframe(ax25_cb *ax25, struct
skb->dev = ax25->ax25_dev->dev;
skb->pkt_type = PACKET_HOST;
skb->protocol = htons(ETH_P_IP);
- ip_rcv(skb, skb->dev, NULL); /* Wrong ptype */
+ netif_rx(skb);
return 1;
}
-#endif
if (pid == AX25_P_SEGMENT) {
skb_pull(skb, 1); /* Remove PID */
return ax25_rx_fragment(ax25, skb);
@@ -250,7 +245,6 @@ static int ax25_rcv(struct sk_buff *skb,
/* Now we are pointing at the pid byte */
switch (skb->data[1]) {
-#ifdef CONFIG_INET
case AX25_P_IP:
skb_pull(skb,2); /* drop PID/CTRL */
skb->h.raw = skb->data;
@@ -258,7 +252,7 @@ static int ax25_rcv(struct sk_buff *skb,
skb->dev = dev;
skb->pkt_type = PACKET_HOST;
skb->protocol = htons(ETH_P_IP);
- ip_rcv(skb, dev, ptype); /* Note ptype here is the wrong one, fix me later */
+ netif_rx(skb);
break;
case AX25_P_ARP:
@@ -268,9 +262,8 @@ static int ax25_rcv(struct sk_buff *skb,
skb->dev = dev;
skb->pkt_type = PACKET_HOST;
skb->protocol = htons(ETH_P_ARP);
- arp_rcv(skb, dev, ptype); /* Note ptype here is wrong... */
+ netif_rx(skb);
break;
-#endif
case AX25_P_TEXT:
/* Now find a suitable dgram socket */
sk = ax25_get_socket(&dest, &src, SOCK_DGRAM);
Index: linux-cvs/net/netrom/af_netrom.c
===================================================================
--- linux-cvs.orig/net/netrom/af_netrom.c
+++ linux-cvs/net/netrom/af_netrom.c
@@ -858,17 +858,16 @@ int nr_rx_frame(struct sk_buff *skb, str
frametype = skb->data[19] & 0x0F;
flags = skb->data[19] & 0xF0;
-#ifdef CONFIG_INET
/*
* Check for an incoming IP over NET/ROM frame.
*/
- if (frametype == NR_PROTOEXT && circuit_index == NR_PROTO_IP && circuit_id == NR_PROTO_IP) {
+ if (frametype == NR_PROTOEXT &&
+ circuit_index == NR_PROTO_IP && circuit_id == NR_PROTO_IP) {
skb_pull(skb, NR_NETWORK_LEN + NR_TRANSPORT_LEN);
skb->h.raw = skb->data;
return nr_rx_ip(skb, dev);
}
-#endif
/*
* Find an existing socket connection, based on circuit ID, if it's
Index: linux-cvs/net/netrom/nr_dev.c
===================================================================
--- linux-cvs.orig/net/netrom/nr_dev.c
+++ linux-cvs/net/netrom/nr_dev.c
@@ -38,8 +38,6 @@
#include <net/ax25.h>
#include <net/netrom.h>
-#ifdef CONFIG_INET
-
/*
* Only allow IP over NET/ROM frames through if the netrom device is up.
*/
@@ -64,11 +62,12 @@ int nr_rx_ip(struct sk_buff *skb, struct
skb->nh.raw = skb->data;
skb->pkt_type = PACKET_HOST;
- ip_rcv(skb, skb->dev, NULL);
+ netif_rx(skb);
return 1;
}
+#ifdef CONFIG_INET
static int nr_rebuild_header(struct sk_buff *skb)
{
^ permalink raw reply
* Re: Route cache performance
From: Simon Kirby @ 2005-08-24 16:06 UTC (permalink / raw)
To: netdev
On Wed, Aug 24, 2005 at 04:59:32PM +0200, Robert Olsson wrote:
> You could probably also try to set hash table very large.
> via the boot option rt_hash_entries.
I have, and it just grows until it uses up all memory and kills my SSH
session.
> and gc_thresh to 1/4 of that as an experiment.
The threshold appears to have no difference except for where it settles
once I stop the DoS traffic.
> Also if you find any 2.6 version that work a la 2.4 it's
> a good start.
It's weird because 2.6.11 is a lot better in that the GC appears to work
for some time, but it eventually something happens and it also hits
max_size and overflows continually. I think I'm going to have to find a
version that works consistently as opposed to being "a little better".
I was just testing it again and noticed that on 2.6.11 it seems to be
almost stable at 71,000 entries (max_size = 131072) but as soon as I type
"dmesg" in another SSH window it will hit 131072. It's as if it's at
equilibrium with the packet creation.
It may just be as simple as something that has always been buggy but
doesn't show up in 2.4 because the e1000 driver is more efficient there
(and/or some other piece of networking, which appears to be more likely).
Simon-
^ permalink raw reply
* [2.6 patch] include/net/ip_vs.h: "extern inline" -> "static inline"
From: Adrian Bunk @ 2005-08-24 15:58 UTC (permalink / raw)
To: wensong, ja; +Cc: netdev, linux-kernel
"extern inline" doesn't make much sense.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.13-rc6-mm2-full/include/net/ip_vs.h.old 2005-08-24 16:51:58.000000000 +0200
+++ linux-2.6.13-rc6-mm2-full/include/net/ip_vs.h 2005-08-24 16:51:38.000000000 +0200
@@ -958,7 +958,7 @@
*/
#define IP_VS_FWD_METHOD(cp) (cp->flags & IP_VS_CONN_F_FWD_MASK)
-extern __inline__ char ip_vs_fwd_tag(struct ip_vs_conn *cp)
+static inline char ip_vs_fwd_tag(struct ip_vs_conn *cp)
{
char fwd;
^ permalink raw reply
* netdev-2.6 queue updated
From: Jeff Garzik @ 2005-08-24 6:57 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
Recent updates:
* various minor fixes and feature additions
git users: 'ALL' branch of
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
Patch:
http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.13-rc7-netdev1.patch.bz2
drivers/net/wireless/ieee802_11.h | 78
Documentation/networking/README.ipw2100 | 246
Documentation/networking/README.ipw2200 | 290
Documentation/networking/cxgb.txt | 352 +
Documentation/networking/phy.txt | 288
MAINTAINERS | 13
drivers/net/Kconfig | 52
drivers/net/Makefile | 4
drivers/net/Space.c | 12
drivers/net/bonding/bond_alb.c | 17
drivers/net/bonding/bond_main.c | 58
drivers/net/bonding/bonding.h | 3
drivers/net/chelsio/Makefile | 11
drivers/net/chelsio/common.h | 314
drivers/net/chelsio/cphy.h | 148
drivers/net/chelsio/cpl5_cmd.h | 145
drivers/net/chelsio/cxgb2.c | 1256 +++
drivers/net/chelsio/elmer0.h | 151
drivers/net/chelsio/espi.c | 346 +
drivers/net/chelsio/espi.h | 68
drivers/net/chelsio/gmac.h | 134
drivers/net/chelsio/mv88x201x.c | 252
drivers/net/chelsio/pm3393.c | 826 ++
drivers/net/chelsio/regs.h | 468 +
drivers/net/chelsio/sge.c | 1684 +++++
drivers/net/chelsio/sge.h | 105
drivers/net/chelsio/subr.c | 812 ++
drivers/net/chelsio/suni1x10gexp_regs.h | 213
drivers/net/e100.c | 225
drivers/net/e1000/e1000_main.c | 4
drivers/net/eepro100.c | 8
drivers/net/forcedeth.c | 582 +
drivers/net/hamradio/baycom_epp.c | 3
drivers/net/hamradio/baycom_par.c | 3
drivers/net/hamradio/baycom_ser_fdx.c | 3
drivers/net/hamradio/baycom_ser_hdx.c | 3
drivers/net/hamradio/mkiss.c | 3
drivers/net/ixgb/ixgb.h | 2
drivers/net/ixgb/ixgb_ee.c | 170
drivers/net/ixgb/ixgb_ethtool.c | 59
drivers/net/ixgb/ixgb_hw.h | 9
drivers/net/ixgb/ixgb_main.c | 53
drivers/net/jazzsonic.c | 186
drivers/net/loopback.c | 22
drivers/net/macsonic.c | 542 -
drivers/net/mv643xx_eth.c | 29
drivers/net/mv643xx_eth.h | 4
drivers/net/pci-skeleton.c | 6
drivers/net/pcmcia/fmvj18x_cs.c | 25
drivers/net/phy/Kconfig | 49
drivers/net/phy/Makefile | 9
drivers/net/phy/cicada.c | 134
drivers/net/phy/davicom.c | 195
drivers/net/phy/lxt.c | 179
drivers/net/phy/marvell.c | 140
drivers/net/phy/mdio_bus.c | 99
drivers/net/phy/phy.c | 690 ++
drivers/net/phy/phy_device.c | 572 +
drivers/net/phy/qsemi.c | 143
drivers/net/r8169.c | 1
drivers/net/s2io-regs.h | 85
drivers/net/s2io.c | 3095 +++++----
drivers/net/s2io.h | 364 -
drivers/net/sis190.c | 1842 +++++
drivers/net/skge.c | 63
drivers/net/skge.h | 19
drivers/net/sky2.c | 2686 ++++++++
drivers/net/sky2.h | 1935 +++++
drivers/net/smc91x.c | 159
drivers/net/smc91x.h | 9
drivers/net/sonic.c | 674 +-
drivers/net/sonic.h | 460 -
drivers/net/tokenring/Kconfig | 4
drivers/net/tokenring/abyss.c | 2
drivers/net/tokenring/madgemc.c | 515 -
drivers/net/tokenring/proteon.c | 104
drivers/net/tokenring/skisa.c | 104
drivers/net/tokenring/tms380tr.c | 46
drivers/net/tokenring/tms380tr.h | 9
drivers/net/tokenring/tmspci.c | 4
drivers/net/tulip/Kconfig | 12
drivers/net/tulip/Makefile | 1
drivers/net/tulip/media.c | 36
drivers/net/tulip/timer.c | 1
drivers/net/tulip/tulip.h | 8
drivers/net/tulip/tulip_core.c | 34
drivers/net/tulip/uli526x.c | 1749 +++++
drivers/net/wan/cycx_drv.c | 24
drivers/net/wireless/Kconfig | 106
drivers/net/wireless/Makefile | 6
drivers/net/wireless/airo.c | 65
drivers/net/wireless/atmel.c | 62
drivers/net/wireless/hostap/Kconfig | 71
drivers/net/wireless/hostap/Makefile | 5
drivers/net/wireless/hostap/hostap.c | 1198 +++
drivers/net/wireless/hostap/hostap.h | 57
drivers/net/wireless/hostap/hostap_80211.h | 96
drivers/net/wireless/hostap/hostap_80211_rx.c | 1091 +++
drivers/net/wireless/hostap/hostap_80211_tx.c | 524 +
drivers/net/wireless/hostap/hostap_ap.c | 3288 +++++++++
drivers/net/wireless/hostap/hostap_ap.h | 261
drivers/net/wireless/hostap/hostap_common.h | 435 +
drivers/net/wireless/hostap/hostap_config.h | 55
drivers/net/wireless/hostap/hostap_cs.c | 1030 +++
drivers/net/wireless/hostap/hostap_download.c | 766 ++
drivers/net/wireless/hostap/hostap_hw.c | 3445 ++++++++++
drivers/net/wireless/hostap/hostap_info.c | 499 +
drivers/net/wireless/hostap/hostap_ioctl.c | 4102 ++++++++++++
drivers/net/wireless/hostap/hostap_pci.c | 473 +
drivers/net/wireless/hostap/hostap_plx.c | 645 +
drivers/net/wireless/hostap/hostap_proc.c | 448 +
drivers/net/wireless/hostap/hostap_wlan.h | 1033 +++
drivers/net/wireless/ipw2100.c | 8641 ++++++++++++++++++++++++++
drivers/net/wireless/ipw2100.h | 1195 +++
drivers/net/wireless/ipw2200.c | 7361 ++++++++++++++++++++++
drivers/net/wireless/ipw2200.h | 1770 +++++
drivers/net/wireless/orinoco.c | 89
drivers/net/wireless/strip.c | 2
drivers/net/wireless/wavelan_cs.c | 26
drivers/net/wireless/wavelan_cs.h | 6
drivers/net/wireless/wavelan_cs.p.h | 17
drivers/net/wireless/wl3501.h | 4
drivers/net/wireless/wl3501_cs.c | 11
drivers/usb/net/Makefile | 2
drivers/usb/net/zd1201.c | 16
include/linux/etherdevice.h | 6
include/linux/ethtool.h | 4
include/linux/mii.h | 9
include/linux/pci_ids.h | 1
include/linux/phy.h | 360 +
include/net/ieee80211.h | 9
include/net/ieee80211_crypt.h | 86
net/Kconfig | 1
net/Makefile | 1
net/ieee80211/Kconfig | 69
net/ieee80211/Makefile | 11
net/ieee80211/ieee80211_crypt.c | 259
net/ieee80211/ieee80211_crypt_ccmp.c | 470 +
net/ieee80211/ieee80211_crypt_tkip.c | 708 ++
net/ieee80211/ieee80211_crypt_wep.c | 272
net/ieee80211/ieee80211_module.c | 273
net/ieee80211/ieee80211_rx.c | 1205 +++
net/ieee80211/ieee80211_tx.c | 447 +
net/ieee80211/ieee80211_wx.c | 471 +
144 files changed, 66658 insertions(+), 3447 deletions(-)
Adrian Bunk:
net/ieee80211/ieee80211_tx.c: swapped memset arguments
net/ieee80211/: make two functions static
fix IEEE80211_CRYPT_* selects
ieee80211: remove pci.h #include's
ieee80211: fix recursive ipw2200 dependencies
hostap update
include/net/ieee80211.h must #include <linux/wireless.h>
SIS190 must select MII
Al Viro:
ieee80211_module.c::store_debug_level() cleanup
zd1201 fixes
Andrew Morton:
ipw2100 old gcc fix
wireless-device-attr-fixes
wireless-device-attr-fixes-2
more-u32-vs-pm_message_t-fixes-6
e1000 printk warning fix 2
Andy Fleming:
This patch adds a PHY Abstraction Layer to the Linux Kernel, enabling
Arthur Kepner:
bonding: inherit zero-copy flags of slaves
Brandon Enochs:
hostap update
Christoph Lameter:
A new 10GB Ethernet Driver by Chelsio Communications
Chuck Ebbert:
loopback: #ifdef the TSO code
loopback: optimize stats
loopback: whitespace cleanup
Dale Farnsworth:
mv643xx: add workaround for HW checksum generation bug
Dave Hansen:
hostap update
Finn Thain:
macsonic/jazzsonic network drivers update
Francois Romieu:
sis190: resurrection
sis190: netconsole support.
sis190: ethtool/mii support.
sis190: add MAINTAINER entry.
sis190: merge some register related information from SiS driver.
sis190: remove hardcoded constants.
sis190: initialisation of MAC address.
sis190: the size of the Rx buffer is constrained
sis190: extract bits definition from SiS driver.
sis190: add endian annotations.
sis190: allow a non-hardcoded ID for the PHY.
sis190: dummy read is required by the status register
sis190: new PHY detection code.
sis190: PHY identifier for the K8S-MX motherboard.
sis190: compare the lpa to the local advertisement
r8169: PCI ID for the Linksys EG1032
Henrik Brix Andersen:
hostap update
James Ketrenos:
Add ipw2100 wireless driver.
Add ipw2200 wireless driver.
Jar:
hostap update
Jeff Garzik:
[netdrvr smc91x] use __iomem addresses in eeprom read/write changes
[NET] ieee80211 subsystem
[wireless] ipw2100: fix build after applying SuSE cleanups
wireless: fix ipw warning; add is_broadcast_ether_addr() to linux/etherdevice.h
ieee80211: trim trailing whitespace
[wireless ipw2200] trim trailing whitespace
[wireless hostap] trim trailing whitespace
Fix numerous minor problems with new phy subsystem.
phy subsystem: more cleanups
ieee80211: remove last uses of compat define WLAN_CAPABILITY_BSS
[netdrvr eepro100] check for skb==NULL before calling rx_align(skb)
Jiri Benc:
ieee80211: cleanup
ieee80211: fix ipw 64bit compilation warnings
Jochen Friedrich:
tms380tr: move to DMA API
[netdrvr] Convert madgemc to new MCA API.
tms380tr: remove prototypes in Space.c
John W. Linville:
bonding: ALB -- allow slave to use bond's MAC address if its own MAC address conflicts
Jouni Malinen:
Add HostAP wireless driver.
hostap update
hostap update
hostap update
hostap update
hostap update
hostap update
hostap: Start using net/ieee80211.h
hostap: Replace crypto code with net/ieee80211 version
hostap: Fix skb->cb use for TX meta data
hostap: Remove experimental PCI bus master/DMA code
hostap: Use void *hw_priv instead of #ifdef in local data
hostap: Remove extra defines
hostap: Replace hostap_ieee80211_hdr with ieee80211_hdr
hostap: Use ieee80211 WLAN_FC_GET_{TYPE,STYPE}
ieee80211: Fix frame control pver mask
ieee80211: Capability field is called ESS, not BSS
hostap: Capability field is called ESS, not BSS
hostap: Replace WLAN_FC_ defines with ieee80211 ones
Komuro:
network: fix fmvj18x_cs multicast code
ladis@linux-mips.org:
smc91x: get/set eeprom
Malli Chilakala:
e100: Added cpu cycle saver microcode for 8086:[1209/1229]
e100: Driver version, white space, comments & other
ixgb: Set RXDCTL:PTHRESH/HTHRESH to zero
ixgb: Fix unnecessary link state messages
ixgb: Use netdev_priv() instead of netdev->priv
ixgb: Fix Broadcast/Multicast packets received statistics
ixgb: Fix data output by ethtool -d
ixgb: Ethtool cleanup patch from Stephen Hemminger
ixgb: Remove unused functions
ixgb: Redefined buffer_info-dma to be dma_addr_t instead of uint64
ixgb: Driver version, white space, comments
Manfred Spraul:
forcedeth: Jumbo Frame Support
forcedeth: Improve ethtool support
forcedeth: rewritten tx irq handling
forcedeth: 64-bit DMA support
forcedeth: Add set_mac_address support
forcedeth: write back original mac address during ifdown
forcedeth: Initialize link settings in every nv_open()
Marcelo Feitoza Parisi:
Use time_before in hamradio drivers
Nishanth Aravamudan:
net/cycx_drv: replace delay_cycx() with msleep_interruptible()
Pavel Machek:
ipw2100: remove commented-out code
ipw2100: assume recent kernel
ipw2100: kill dead macros
ipw2100: small cleanups
Pavel Roskin:
hostap update
Peer Chen:
[netdrvr] add 'uli526x' driver (a tulip clone)
[netdrvr tulip] Remove ULi-specific code from generic tulip driver
[netdrvr uli526x] fix problems found in review
Peter Hagervall:
orinoco: Sparse fixes
raghavendra.koushik@neterion.com:
S2io: Code cleanup
S2io: Hardware fixes
S2io: Software fixes
S2io: Removed memory leaks
S2io: Performance improvements
S2io: Support for runtime MTU change
S2io: Timer based slowpath handling
S2io: VLAN support
S2io: Support for Xframe II NIC
S2io: Support for bimodal interrupts
S2io: New link handling scheme for Xframe II
S2io: Miscellaneous fixes
S2io: Errors found during review
ravinandan.arakali@neterion.com:
S2io: Hardware fixes for Xframe II adapter
Richard Purdie:
hostap update
Scott Bardone:
Update Chelsio gige net driver.
Stephen Hemminger:
skge: stop bogus sensor messages
skge: fibre vs copper detection cleanup
skge: increase receive flush threshold default
skge: turn on link status LED
sky2: new experimental Marvell Yukon2 driver
Tobias Klauser:
drivers/net/wireless/ipw2100: Use the DMA_32BIT_MASK constant
drivers/net/wireless/ipw2200: Use the DMA_32BIT_MASK constant
Victor Fusco:
drivers/net/pci-skeleton.c: MODULE_PARM -> module_param
^ permalink raw reply
* Re: Route cache performance
From: Robert Olsson @ 2005-08-24 3:50 UTC (permalink / raw)
To: Simon Kirby; +Cc: Robert Olsson, Eric Dumazet, netdev
In-Reply-To: <20050824000158.GA8137@netnation.com>
Simon Kirby writes:
> Something is definitely broken here. Are the interrupts (or in this
> case, NAPI) able to starve the gc somehow?
Hmm no in 2.6 dst entries are freed via RCU callback this had problems
but was redesigned.
Reading your old email... Didn't you get "dst cache overflow" before
2.6.11-bk2?
In other case I like to have your detailed setup to see if I get any
idea or possible can reproduced.
Cheers.
--ro
^ permalink raw reply
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