* 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: ieee80211 patches
From: Michael Wu @ 2005-08-26 0:49 UTC (permalink / raw)
To: netdev; +Cc: Jiri Benc, NetDev, Jeff Garzik, jbohac, pavel
In-Reply-To: <20050825193112.529d0dc9@griffin.suse.cz>
On Thursday 25 August 2005 13:31, Jiri Benc wrote:
> Our patches against latest ieee80211 branch can be found at
> http://kernel.org/pub/linux/kernel/people/jbenc/
>
I hope to submit the adm8211 driver for review soon, but there's a bunch of
code in the driver which probably belong in the ieee80211 code:
- Duplicate frame removal
- Definitions for all management payloads
- SIOCSIWENCODEEXT and SIOCGIWENCODEEXT
- AVS capture header in monitor mode
- Software Scanning
- Software Authentication & Association
Does that sound okay? I will start submitting patches to add those things if
they should be in the ieee80211 code.
Thanks,
-Michael Wu
^ permalink raw reply
* Re: 2.6.12 Performance problems
From: Danial Thom @ 2005-08-26 3:29 UTC (permalink / raw)
To: Ben Greear; +Cc: Jesper Juhl, linux-kernel, netdev
In-Reply-To: <430D620A.6050204@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.
>
> > 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
It would be useful if there were some way to find
out "what" is getting "robbed". If networking has
priority, then what is keeping it from getting
back to processing the rx interrupts?
Ah, the e1000 has built-in interrupt moderation.
I can't get into my lab until tomorrow afternoon,
but if you get a chance try setting ITR in
e1000_main.c to something larger, like 20K. and
see if it makes a difference. At 200K pps that
would cause an interrupt every 10 packets, which
may allow the routine to grab back the cpu more
often.
Danial
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: oops in 2.6.13-rc6-git12 in tcp/netfilter routines
From: Harald Welte @ 2005-08-26 8:35 UTC (permalink / raw)
To: Sven Schuster
Cc: Alessandro Suardi, netdev, Linux Kernel Mailing List,
netfilter-devel
In-Reply-To: <20050825210200.GA10374@zion.homelinux.com>
[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]
On Thu, Aug 25, 2005 at 11:02:01PM +0200, Sven Schuster wrote:
>
> 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/
ok, thanks. Sorry for the confusion, but the 'official' website is just
a blog that didn't really reveal all that much information.
--
- 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: ieee80211 patches
From: Stefan Rompf @ 2005-08-26 9:04 UTC (permalink / raw)
To: Michael Wu; +Cc: netdev, Jiri Benc, NetDev, Jeff Garzik, jbohac, pavel
In-Reply-To: <200508252049.52413.flamingice@sourmilk.net>
Hi,
Am Freitag 26 August 2005 02:49 schrieb Michael Wu:
> I hope to submit the adm8211 driver for review soon, but there's a bunch of
> code in the driver which probably belong in the ieee80211 code:
[...]
> - AVS capture header in monitor mode
there has been a discussion about AVS or radiotap header on the ipw list that
resulted in the inclusion of radiotap definitions in James' latest patches
for ieee80211. Radiotap requires a libpcap upgrade, but can be extended
easier. I'd like all linux wireless drivers to move to radiotap for statistic
data so that userspace has just one format to parse, and a new driver would
be a perfect target to begin.
Stefan
^ permalink raw reply
* Re: Route cache performance
From: Alexey Kuznetsov @ 2005-08-26 11:55 UTC (permalink / raw)
To: Simon Kirby; +Cc: Alexey Kuznetsov, Robert Olsson, Eric Dumazet, netdev
In-Reply-To: <20050825212211.GA23384@netnation.com>
Hello!
> What part of the code will decrement the count? I can't see it.
It depends. In the case of forwarding, it is kfree_skb(), happening
after the packet is transmitted by output device.
Well, it could result in overflow only if device queue is longer
than route/max_size.
Alexey
^ permalink raw reply
* Re: ieee80211 patches
From: Jiri Benc @ 2005-08-26 12:08 UTC (permalink / raw)
To: Michael Wu; +Cc: netdev, NetDev, Jeff Garzik, jbohac, pavel
In-Reply-To: <200508252049.52413.flamingice@sourmilk.net>
On Thu, 25 Aug 2005 20:49:52 -0400, Michael Wu wrote:
> I hope to submit the adm8211 driver for review soon, but there's a bunch of
> code in the driver which probably belong in the ieee80211 code:
>
> - Duplicate frame removal
> - Definitions for all management payloads
> - SIOCSIWENCODEEXT and SIOCGIWENCODEEXT
> - AVS capture header in monitor mode
> - Software Scanning
> - Software Authentication & Association
>
> Does that sound okay? I will start submitting patches to add those things if
> they should be in the ieee80211 code.
Sounds great. Could you post a pointer to the project?
Btw, Andrea Merello has a code for some of these features in his
rtl8180-sa2400 project (http://sourceforge.net/projects/rtl8180-sa2400)
too - we are trying to subsequently include them.
Thanks,
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* Re: ieee80211 patches
From: Michael Wu @ 2005-08-26 13:59 UTC (permalink / raw)
To: Stefan Rompf; +Cc: netdev, Jiri Benc, NetDev, Jeff Garzik, jbohac, pavel
In-Reply-To: <200508261104.16134.stefan@loplof.de>
On Friday 26 August 2005 05:04, Stefan Rompf wrote:
> > - AVS capture header in monitor mode
>
> there has been a discussion about AVS or radiotap header on the ipw list
> that resulted in the inclusion of radiotap definitions in James' latest
> patches for ieee80211. Radiotap requires a libpcap upgrade, but can be
> extended easier. I'd like all linux wireless drivers to move to radiotap
> for statistic data so that userspace has just one format to parse, and a
> new driver would be a perfect target to begin.
>
Sounds like everyone agrees that radiotap is a superior header. I will remove
AVS support and add radiotap support (if additional code is needed) once
radiotap code is merged in ieee80211.
Thanks,
-Michael Wu
^ permalink raw reply
* Re: ieee80211 patches
From: Michael Wu @ 2005-08-26 15:07 UTC (permalink / raw)
To: Jiri Benc; +Cc: netdev, NetDev, Jeff Garzik, jbohac, pavel
In-Reply-To: <20050826140831.5ec0f301@griffin.suse.cz>
On Friday 26 August 2005 08:08, Jiri Benc wrote:
> On Thu, 25 Aug 2005 20:49:52 -0400, Michael Wu wrote:
> > I hope to submit the adm8211 driver for review soon, but there's a bunch
> > of code in the driver which probably belong in the ieee80211 code:
> >
> > - Duplicate frame removal
> > - Definitions for all management payloads
> > - SIOCSIWENCODEEXT and SIOCGIWENCODEEXT
> > - AVS capture header in monitor mode
> > - Software Scanning
> > - Software Authentication & Association
> >
> > Does that sound okay? I will start submitting patches to add those things
> > if they should be in the ieee80211 code.
>
> Sounds great. Could you post a pointer to the project?
>
http://aluminum.sourmilk.net/adm8211/index.php?path=netdev/
> Btw, Andrea Merello has a code for some of these features in his
> rtl8180-sa2400 project (http://sourceforge.net/projects/rtl8180-sa2400)
> too - we are trying to subsequently include them.
>
Hmm..
- adm8211 supports shared key authentication, rtl8180-sa2400 only supports
open authentication. (which is kinda okay when you consider that 802.11i
doesn't use shared key)
- Both drivers do not support LEAP authentication.
- adm8211 supports WE18/WPA (partly via SIWGENIE, it doesn't generate WPA/RSN
IEs itself)
- rtl8180-sa2400 supports a really simple master mode. (should something like
hostapd be used instead for master mode?)
- rtl8180-sa2400 supports sending probe responses. adm8211 lets the hardware
do it, though newer adm8211 cards can be told to hand it off to the software.
- rtl8180-sa2400 creates a completely random bssid in adhoc. adm8211 keeps the
first 3 octets from the MAC addr.
- adm8211 supports sending & handling deauthentication and disassociation
frames. I did not see definitions for those frames, so I assume there's no
support there.
- adm8211 needs many hooks in scanning/authentication/association to set
BSSID/SSID/AID/etc. in hardware.
- rtl8180-sa2400 doesn't seem to convert to little endian in a number of
places. (not really major..)
-Michael Wu
^ permalink raw reply
* Re: oops in 2.6.13-rc6-git12 in tcp/netfilter routines
From: Patrick McHardy @ 2005-08-26 17:52 UTC (permalink / raw)
To: Alessandro Suardi; +Cc: netdev, Linux Kernel Mailing List, netfilter-devel
In-Reply-To: <5a4c581d05082506395fa984ae@mail.gmail.com>
Alessandro Suardi wrote:
> 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.
Any chance you can get the entire Oops including registers etc
using netconsole or serial console?
^ permalink raw reply
* Re: 2.6.12 Performance problems
From: Benjamin LaHaise @ 2005-08-26 19:10 UTC (permalink / raw)
To: Ben Greear; +Cc: danial_thom, Jesper Juhl, linux-kernel, netdev
In-Reply-To: <430DF7FF.9080502@candelatech.com>
On Thu, Aug 25, 2005 at 09:55:27AM -0700, Ben Greear wrote:
> 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).
There should be a number of decent boards out on the market these days.
Try picking up one with a CSA gige adapter (a dedicated high bandwidth
link to an e1000) or PCI Express (although that is harder to pick up on
from the specifications of most motherboards).
-ben
^ permalink raw reply
* [PATCH 4/7] [IPV4]: Fix DST leak in icmp_push_reply()
From: Chris Wright @ 2005-08-26 19:17 UTC (permalink / raw)
To: linux-kernel, stable, Ollie Wild
Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap,
Chuck Wolber, torvalds, akpm, alan, Maillist netdev,
Patrick McHardy, David S. Miller, Chris Wright
In-Reply-To: <20050826191755.052951000@localhost.localdomain>
[-- Attachment #1: fix-dst-leak-in-icmp_push_reply.patch --]
[-- Type: text/plain, Size: 1332 bytes --]
-stable review patch. If anyone has any objections, please let us know.
------------------
Based upon a bug report and initial patch by
Ollie Wild.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@osdl.org>
---
net/ipv4/icmp.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
Index: linux-2.6.12.y/net/ipv4/icmp.c
===================================================================
--- linux-2.6.12.y.orig/net/ipv4/icmp.c
+++ linux-2.6.12.y/net/ipv4/icmp.c
@@ -349,12 +349,12 @@ static void icmp_push_reply(struct icmp_
{
struct sk_buff *skb;
- ip_append_data(icmp_socket->sk, icmp_glue_bits, icmp_param,
- icmp_param->data_len+icmp_param->head_len,
- icmp_param->head_len,
- ipc, rt, MSG_DONTWAIT);
-
- if ((skb = skb_peek(&icmp_socket->sk->sk_write_queue)) != NULL) {
+ if (ip_append_data(icmp_socket->sk, icmp_glue_bits, icmp_param,
+ icmp_param->data_len+icmp_param->head_len,
+ icmp_param->head_len,
+ ipc, rt, MSG_DONTWAIT) < 0)
+ ip_flush_pending_frames(icmp_socket->sk);
+ else if ((skb = skb_peek(&icmp_socket->sk->sk_write_queue)) != NULL) {
struct icmphdr *icmph = skb->h.icmph;
unsigned int csum = 0;
struct sk_buff *skb1;
--
^ permalink raw reply
* Re: Route cache performance
From: Robert Olsson @ 2005-08-26 19:49 UTC (permalink / raw)
To: Alexey Kuznetsov; +Cc: Simon Kirby, Robert Olsson, Eric Dumazet, netdev
In-Reply-To: <20050826115520.GA12351@yakov.inr.ac.ru>
Hello!
This thread seems familar :)
I think Simon uses UP and it could be idea to check if the RCU deferred
deletion causes the problem.
Simon it would be interesting to see if the patch below makes any
difference given the assumption about UP was correct,
Cheers.
--ro
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -485,7 +485,11 @@ static struct file_operations rt_cpu_seq
static __inline__ void rt_free(struct rtable *rt)
{
multipath_remove(rt);
+#ifdef CONFIG_SMP
call_rcu_bh(&rt->u.dst.rcu_head, dst_rcu_free);
+#else
+ dst_free((struct dst_entry *)rt);
+#endif
}
static __inline__ void rt_drop(struct rtable *rt)
^ permalink raw reply
* Re: oops in 2.6.13-rc6-git12 in tcp/netfilter routines
From: Alessandro Suardi @ 2005-08-26 20:40 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, Linux Kernel Mailing List, netfilter-devel
In-Reply-To: <430F56C7.8070500@trash.net>
On 8/26/05, Patrick McHardy <kaber@trash.net> wrote:
> Alessandro Suardi wrote:
> > 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.
>
> Any chance you can get the entire Oops including registers etc
> using netconsole or serial console?
Not right now, as I noticed netconsole requires netpoll and this
latter can't be modular; but I'll do so before leaving tomorrow
morning, obviously rebuilding with 2.6.13-rc7-git1 or -git2 if
the new snapshot comes out.
At the moment, the box has been running for 32 hours with
no sign of wanting to oops...
[root@donkey ~]# ps ax | egrep 'peer|edon'
2416 pts/2 Sl 25:37 peerguardnf -d -l /var/log/pg.log -c /etc/PG.conf
25186 pts/0 R+ 76:37 ./edonkey2000
25189 pts/0 S+ 0:06 ./edonkey2000
25191 pts/0 S+ 9:49 ./edonkey2000
7007 pts/0 S+ 0:00 ./edonkey2000
7011 pts/3 R+ 0:00 egrep peer|edon
[root@donkey ~]# w
22:37:53 up 1 day, 7:49, 4 users, load average: 0.15, 0.18, 0.25
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
root pts/0 donkey:2.0 Thu14 20:15m 1:26m 0.00s bash
root pts/1 donkey:2.0 Thu14 13:40m 0.41s 1:57
gnome-terminal --sm-config-prefix /gnome-terminal-wBjEOn/ -
root pts/2 donkey:2.0 Thu14 4:07 25:37 0.49s bash
root pts/3 192.168.1.6 22:37 0.00s 0.06s 0.01s w
Thanks,
--alessandro
"Not every smile means I'm laughing inside"
(Wallflowers - "From The Bottom Of My Heart")
^ permalink raw reply
* Re: 2.6.12 Performance problems
From: Danial Thom @ 2005-08-26 22:18 UTC (permalink / raw)
To: Ben Greear; +Cc: Jesper Juhl, linux-kernel, netdev
In-Reply-To: <20050826032938.59796.qmail@web33303.mail.mud.yahoo.com>
--- Danial Thom <danial_thom@yahoo.com> wrote:
>
>
> --- 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.
> >
> > > 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
>
> It would be useful if there were some way to
> find
> out "what" is getting "robbed". If networking
> has
> priority, then what is keeping it from getting
> back to processing the rx interrupts?
>
> Ah, the e1000 has built-in interrupt
> moderation.
> I can't get into my lab until tomorrow
> afternoon,
> but if you get a chance try setting ITR in
> e1000_main.c to something larger, like 20K. and
> see if it makes a difference. At 200K pps that
> would cause an interrupt every 10 packets,
> which
> may allow the routine to grab back the cpu more
> often.
>
>
> Danial
>
Just FYI, setting interrupt moderation to 20,000
didn't make much difference.
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
^ permalink raw reply
* Re: ieee80211 patches
From: Michael Wu @ 2005-08-26 23:50 UTC (permalink / raw)
To: netdev; +Cc: Jiri Benc, NetDev, Jeff Garzik, jbohac, pavel
In-Reply-To: <20050826181329.6dcf94d3@griffin.suse.cz>
On Friday 26 August 2005 12:13, Jiri Benc wrote:
> You mentioned problem with hooks in scanning/association/etc. Probably
> everybody involved in this discussion knows it but I think it is worth
> saying it: This is one of the most important things in a new ieee80211
> layer. Unfortunately, it seems that every driver developer concentrates
> on the aspects of his device (this include ieee80211 layer from ipw as
> well as from rtl8180). But every device (or more precisely firmware)
> provides different set of features - some takes care of almost
> everything, other can do basic things only. So the amount of work that
> needs to be done in the ieee80211 layer is different for different
> devices. The layer has to be generic. It has to cope e.g. with
> authentication/association performed fully by itself as well as with
> auth/assoc performed automatically by the device, etc.
>
> I'm convinced this is the first goal we have to reach before we start to
> implement WPA, QoS and so.
Right now, the adm8211 driver uses a number of specific hooks in its own
ieee80211 station management code such as:
set_bssid
set_ssid
set_channel
set_interval
set_beacon
Though with enough of these hooks, many devices can be supported, I think
generic hooks like these would work best to support a wide range of hardware
that use softmac:
pre_scan
set_channel
pre_associate
link_change
start_ibss
join_ibss
Then for the devices that do more in the firmware, adding callbacks like:
hw_scan
hw_associate
hw_start_ibss
would indicate to the ieee80211 layer that the hardware is capable of handling
those things itself.
The driver should be able to find all the info needed to configure the
hardware in ieee80211_device so only that needs to be passed to the hooks.
A good portion of WPA can be implemented right now by implementing the
encodeext ioctls and generalizing ieee80211_security to support more than
just WEP. adm8211 doesn't have support for non-wep encryption yet, so WPA
works without ieee80211_security support.
Sound good?
-Michael Wu
^ permalink raw reply
* Leaked net-device reference in eql.c
From: Ben Greear @ 2005-08-27 0:08 UTC (permalink / raw)
To: 'netdev@oss.sgi.com'
Hello!
I think the eql_s_slave_cfg method in eql.c leaks
the reference to slave_dev. Am I missing something?
static int eql_s_slave_cfg(struct net_device *dev, slave_config_t __user *scp)
{
slave_t *slave;
equalizer_t *eql;
struct net_device *slave_dev;
slave_config_t sc;
int ret;
if (copy_from_user(&sc, scp, sizeof (slave_config_t)))
return -EFAULT;
slave_dev = dev_get_by_name(sc.slave_name);
if (!slave_dev)
return -ENODEV;
ret = -EINVAL;
eql = netdev_priv(dev);
spin_lock_bh(&eql->queue.lock);
if (eql_is_slave(slave_dev)) {
slave = __eql_find_slave_dev(&eql->queue, slave_dev);
if (slave) {
slave->priority = sc.priority;
slave->priority_bps = sc.priority;
slave->priority_Bps = sc.priority / 8;
ret = 0;
}
}
spin_unlock_bh(&eql->queue.lock);
return ret;
}
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Leaked net-device reference in eql.c
From: Patrick McHardy @ 2005-08-27 3:38 UTC (permalink / raw)
To: Ben Greear; +Cc: 'netdev@oss.sgi.com'
In-Reply-To: <430FAF0D.5050000@candelatech.com>
Ben Greear wrote:
> I think the eql_s_slave_cfg method in eql.c leaks
> the reference to slave_dev. Am I missing something?
No, it should also put the device, as in eql_g_slave_cfg.
^ permalink raw reply
* Re: Leaked net-device reference in eql.c
From: Ben Greear @ 2005-08-27 6:24 UTC (permalink / raw)
To: Patrick McHardy; +Cc: 'netdev@oss.sgi.com'
In-Reply-To: <430FE01E.9020600@trash.net>
Patrick McHardy wrote:
> Ben Greear wrote:
>
>> I think the eql_s_slave_cfg method in eql.c leaks
>> the reference to slave_dev. Am I missing something?
>
>
> No, it should also put the device, as in eql_g_slave_cfg.
Ok, I'm making a patch...will add this to it.
How about this one. It seems like it does a dev_put when it shouldn't
(if some of the if's fail, the dev_get never happened):
net/sched/sch_generic.c
static void dev_watchdog(unsigned long arg)
{
struct net_device *dev = (struct net_device *)arg;
spin_lock(&dev->xmit_lock);
if (dev->qdisc != &noop_qdisc) {
if (netif_device_present(dev) &&
netif_running(dev) &&
netif_carrier_ok(dev)) {
if (netif_queue_stopped(dev) &&
(jiffies - dev->trans_start) > dev->watchdog_timeo) {
printk(KERN_INFO "NETDEV WATCHDOG: %s: transmit timed out\n", dev->name);
dev->tx_timeout(dev);
}
if (!mod_timer(&dev->watchdog_timer, jiffies + dev->watchdog_timeo))
dev_hold(dev);
}
}
spin_unlock(&dev->xmit_lock);
dev_put(dev);
}
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Leaked net-device reference in eql.c
From: Arnaldo Carvalho de Melo @ 2005-08-27 9:37 UTC (permalink / raw)
To: Ben Greear; +Cc: Patrick McHardy, netdev@oss.sgi.com
In-Reply-To: <43100709.1090800@candelatech.com>
On 8/27/05, Ben Greear <greearb@candelatech.com> wrote:
> Patrick McHardy wrote:
> > Ben Greear wrote:
> >
> >> I think the eql_s_slave_cfg method in eql.c leaks
> >> the reference to slave_dev. Am I missing something?
> >
> >
> > No, it should also put the device, as in eql_g_slave_cfg.
>
> Ok, I'm making a patch...will add this to it.
>
> How about this one. It seems like it does a dev_put when it shouldn't
> (if some of the if's fail, the dev_get never happened):
>
> net/sched/sch_generic.c
>
> static void dev_watchdog(unsigned long arg)
> {
> struct net_device *dev = (struct net_device *)arg;
>
> spin_lock(&dev->xmit_lock);
> if (dev->qdisc != &noop_qdisc) {
> if (netif_device_present(dev) &&
> netif_running(dev) &&
> netif_carrier_ok(dev)) {
> if (netif_queue_stopped(dev) &&
> (jiffies - dev->trans_start) > dev->watchdog_timeo) {
> printk(KERN_INFO "NETDEV WATCHDOG: %s: transmit timed out\n", dev->name);
> dev->tx_timeout(dev);
> }
> if (!mod_timer(&dev->watchdog_timer, jiffies + dev->watchdog_timeo))
> dev_hold(dev);
> }
> }
> spin_unlock(&dev->xmit_lock);
>
> dev_put(dev);
> }
Doesn't look like its a problem, its the classical case where when you
associate some data structure to a timer you grab a refcount, when the
timer expires you drop the refcount, and as the code above shows when
mod_timer is succesfully called it grabs a reference, so the reference
being dropped above is from the previous timer firing, now its just a matter
if looking for the first mod_timer, that must be at some other place in
sched_generic.c, lemme see...
^ permalink raw reply
* Re: Leaked net-device reference in eql.c
From: Arnaldo Carvalho de Melo @ 2005-08-27 9:39 UTC (permalink / raw)
To: Ben Greear; +Cc: Patrick McHardy, netdev@oss.sgi.com
In-Reply-To: <39e6f6c705082702372dbc902d@mail.gmail.com>
On 8/27/05, Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com> wrote:
> On 8/27/05, Ben Greear <greearb@candelatech.com> wrote:
> > Patrick McHardy wrote:
> > > Ben Greear wrote:
> > >
> > >> I think the eql_s_slave_cfg method in eql.c leaks
> > >> the reference to slave_dev. Am I missing something?
> > >
> > >
> > > No, it should also put the device, as in eql_g_slave_cfg.
> >
> > Ok, I'm making a patch...will add this to it.
> >
> > How about this one. It seems like it does a dev_put when it shouldn't
> > (if some of the if's fail, the dev_get never happened):
> >
> > net/sched/sch_generic.c
> >
> > static void dev_watchdog(unsigned long arg)
> > {
> > struct net_device *dev = (struct net_device *)arg;
> >
> > spin_lock(&dev->xmit_lock);
> > if (dev->qdisc != &noop_qdisc) {
> > if (netif_device_present(dev) &&
> > netif_running(dev) &&
> > netif_carrier_ok(dev)) {
> > if (netif_queue_stopped(dev) &&
> > (jiffies - dev->trans_start) > dev->watchdog_timeo) {
> > printk(KERN_INFO "NETDEV WATCHDOG: %s: transmit timed out\n", dev->name);
> > dev->tx_timeout(dev);
> > }
> > if (!mod_timer(&dev->watchdog_timer, jiffies + dev->watchdog_timeo))
> > dev_hold(dev);
> > }
> > }
> > spin_unlock(&dev->xmit_lock);
> >
> > dev_put(dev);
> > }
>
> Doesn't look like its a problem, its the classical case where when you
> associate some data structure to a timer you grab a refcount, when the
> timer expires you drop the refcount, and as the code above shows when
> mod_timer is succesfully called it grabs a reference, so the reference
> being dropped above is from the previous timer firing, now its just a matter
> if looking for the first mod_timer, that must be at some other place in
> sched_generic.c, lemme see...
Yup, look at __netdev_watchdog_up :-)
- Arnaldo
^ permalink raw reply
* Re: 2.6.12 Performance problems
From: Vladimir B. Savkin @ 2005-08-27 11:19 UTC (permalink / raw)
To: Danial Thom; +Cc: Ben Greear, Jesper Juhl, linux-kernel, netdev
In-Reply-To: <20050825060843.15874.qmail@web33311.mail.mud.yahoo.com>
On Wed, Aug 24, 2005 at 11:08:43PM -0700, Danial Thom wrote:
> If your test is still set up, try compiling
> something large while doing the test. The drops
> go through the roof in my tests.
>
Couldn't this happen because ksoftirqd by default
has a nice value of 19?
~
:wq
With best regards,
Vladimir Savkin.
^ permalink raw reply
* Re: 2.6.12 Performance problems
From: Danial Thom @ 2005-08-27 14:35 UTC (permalink / raw)
To: Vladimir B. Savkin; +Cc: Ben Greear, Jesper Juhl, linux-kernel, netdev
In-Reply-To: <20050827111904.GA6484@tentacle.sectorb.msk.ru>
--- "Vladimir B. Savkin" <master@sectorb.msk.ru>
wrote:
> On Wed, Aug 24, 2005 at 11:08:43PM -0700,
> Danial Thom wrote:
> > If your test is still set up, try compiling
> > something large while doing the test. The
> drops
> > go through the roof in my tests.
> >
> Couldn't this happen because ksoftirqd by
> default
> has a nice value of 19?
>
> ~
> :wq
> With
> best regards,
>
> Vladimir Savkin.
renicing ksoftirqd improves it a bit, but
still tons of loss, even at only 120Kpps.
Danial
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
^ permalink raw reply
* [git patches] 2.6.x net driver fixes
From: Jeff Garzik @ 2005-08-28 0:10 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton; +Cc: Linux Kernel, Netdev List
[-- Attachment #1: Type: text/plain, Size: 195 bytes --]
Please pull from the 'upstream-fixes' branch of
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
to obtain the fixes described in the diffstat/changelog/patch attached.
[-- Attachment #2: netdev-2.6.txt --]
[-- Type: text/plain, Size: 2040 bytes --]
drivers/net/hamradio/6pack.c | 9 +++------
1 files changed, 3 insertions(+), 6 deletions(-)
commit 214838a2108b4b1e18abce2e28d37996e9bf7c68
Author: Ralf Baechle <ralf@linux-mips.org>
Date: Wed Aug 24 18:01:33 2005 +0100
[PATCH] Fix 6pack setting of MAC address
Don't check type of sax25_family; dev_set_mac_address has already done
that before and anyway, the type to check against would have been
ARPHRD_AX25. We only got away because AF_AX25 and ARPHRD_AX25 both happen
to be defined to the same value.
Don't check sax25_ndigis either; it's value is insignificant for the
purpose of setting the MAC address and the check has shown to break
some application software for no good reason.
Signed-off-by: Ralf Baechle DL5RB <ralf@linux-mips.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
commit 84a2ea1c2cee0288f96e0c6aa4f975d4d26508c7
Author: Ralf Baechle <ralf@linux-mips.org>
Date: Thu Aug 25 19:38:30 2005 +0100
[PATCH] 6pack Timer initialization
I dropped the timer initialization bits by accident when sending the
p-persistence fix. This patch gets the driver to work again on halfduplex
links.
Signed-off-by: Ralf Baechle DL5RB <ralf@linux-mips.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
diff --git a/drivers/net/hamradio/6pack.c b/drivers/net/hamradio/6pack.c
--- a/drivers/net/hamradio/6pack.c
+++ b/drivers/net/hamradio/6pack.c
@@ -308,12 +308,6 @@ static int sp_set_mac_address(struct net
{
struct sockaddr_ax25 *sa = addr;
- if (sa->sax25_family != AF_AX25)
- return -EINVAL;
-
- if (!sa->sax25_ndigis)
- return -EINVAL;
-
spin_lock_irq(&dev->xmit_lock);
memcpy(dev->dev_addr, &sa->sax25_call, AX25_ADDR_LEN);
spin_unlock_irq(&dev->xmit_lock);
@@ -668,6 +662,9 @@ static int sixpack_open(struct tty_struc
netif_start_queue(dev);
init_timer(&sp->tx_t);
+ sp->tx_t.function = sp_xmit_on_air;
+ sp->tx_t.data = (unsigned long) sp;
+
init_timer(&sp->resync_t);
spin_unlock_bh(&sp->lock);
^ permalink raw reply
* Netdevice reference counting issues in net/core/dv.c
From: Ben Greear @ 2005-08-28 6:42 UTC (permalink / raw)
To: 'netdev@oss.sgi.com'
dv.c has several issues.
First, it uses the check_args method to find the
device. It acquires a hold on the device and then
drops it in the same method. Upon return from this
check_args method, code then continues to use the reference
to the device. This could lead to access-after-free errors.
Also, check_args has an arbitrary device-index check to make
sure it is less that 1000. This is bogus since we can have many
more devices than that...
If there is a maintainer that wants to fix this, please be my
guest. Otherwise, I'll make a stab at fixing it as part of
my ref-count debugging work.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ 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