Subject: Re: [PATCH 1/4] Net device error logging, revised - msg#00952

Previous Message by Date: click to view message preview

[PATCH] (3/13) atalk_proc whitespace in header

The header for /proc/net/atalk/interfaces is not lined up right with the data because it has a tab rather than spaces. diff -Nru a/net/appletalk/atalk_proc.c b/net/appletalk/atalk_proc.c --- a/net/appletalk/atalk_proc.c Fri Aug 29 11:02:59 2003 +++ b/net/appletalk/atalk_proc.c Fri Aug 29 11:02:59 2003 @@ -64,7 +64,7 @@ struct atalk_iface *iface; if (v == (void *)1) { - seq_puts(seq, "Interface Address Networks " + seq_puts(seq, "Interface Address Networks " "Status\n"); goto out; }

Next Message by Date: click to view message preview

Re: [Linux-ATM-General] Neighbor Table Overflow? (fwd)

It would appear that there is a bug in part of the linux IP stack. I was told that this might be the correct address to send the information to regarding tickling the bug. --- John Fraizer | High-Security Datacenter Services | President | Dedicated circuits 64k - 155M OC3 | EnterZone, Inc | Virtual, Dedicated, Colocation | http://www.enterzone.net/ | Network Consulting Services | ---------- Forwarded message ---------- Date: Fri, 29 Aug 2003 10:26:23 -0400 (EDT) From: John Fraizer <atm@xxxxxxxxxxxxx> To: Mike Westall <westall@xxxxxxxxxxxxxx> Cc: Linux-atm-general <linux-atm-general@xxxxxxxxxxxxxxxxxxxxx> Subject: Re: [Linux-ATM-General] Neighbor Table Overflow? Perhaps someone can pass this up to the right people who do the IP stack. It would appear to be a bug. --- John Fraizer | High-Security Datacenter Services | President | Dedicated circuits 64k - 155M OC3 | EnterZone, Inc | Virtual, Dedicated, Colocation | http://www.enterzone.net/ | Network Consulting Services | On Fri, 29 Aug 2003, Mike Westall wrote: > The interactions between routing and arp are somewhat > complex. This problem seems to have been triggered by > an attempt to route the sunk packets. The message > "overflow" message is issued by rt_intern_hash which > calls arp_bind_neighbour() > > 634 if (rt->rt_type == RTN_UNICAST || rt->key.iif == 0) { > 635 int err = arp_bind_neighbour(&rt->u.dst); > > Apparently arp_bind_neighbour() fails to check for the > NOARP condition. > > > John Fraizer wrote: > > > > Well, in the face of the local microsoft exploits and the worm effects on > > the arp caches of many layer-3 switches and access concentrators, that > > doesn't terribly surprise me. I figured this might be the case but, I > > wasn't sure. The strange part is that "arp -n" doesn't show too aweful > > many entries total. With the typical backscatter we see 24x7 on the net, > > I'll always see a few "incomplete" entries in the arp cache. > > > > The machine in question has a /27 bound up on lec0, a couple of /30's on > > GigE interfaces and a /32 "loopback" address bound up on dummy0. > > > > I do have a sinkhole route for a /19 destined to dummy0. Is it possible > > that the stack is still trying to do ARP when a packet arrives for an > > address in the /19 that doesn't have a more specific route in our IGP and > > it gets dumped to dummy0? > > > > The interface shows: > > > > 4: dummy0: <BROADCAST,NOARP,UP> mtu 1500 qdisc noqueue > > link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff > > > > > > I just removed the static sinkhole route from that route and started > > sinking that traffic (traffic destined for addresses we don't have bound > > up yet) on one of our core routers and the messages went away. > > > > Strange that we would fill the arp cache sinking "garbage" traffic to a > > dummy interface that is set NOARP. > > > > Can anyone explain this to me? > > > > I appreciate it! > > > > --- > > John Fraizer | High-Security Datacenter Services | > > President | Dedicated circuits 64k - 155M OC3 | > > EnterZone, Inc | Virtual, Dedicated, Colocation | > > http://www.enterzone.net/ | Network Consulting Services | > > > > > > On Thu, 28 Aug 2003, Mike Westall wrote: > > > > > >>Appears to be generated because the ARP cache is full. > >>Since the size limits there default to 512 and 1024 entries > >>that would be pretty unusual in most environments unless > >>something else was screwed up in some major way. > >> > >>Hard to say what the something else might be though. > >> > >>MIke > >> > >> > >>John Fraizer wrote: > >> > >> > >>>Can someone tell me specificly what causes the following messages? > >>> > >>>Aug 28 14:27:37 Router kernel: NET: 124 messages suppressed. > >>>Aug 28 14:27:37 Router kernel: Neighbour table overflow. > >>>Aug 28 14:27:37 Router last message repeated 2 times > >>>Aug 28 14:27:39 Router kernel: NET: 207 messages suppressed. > >>>Aug 28 14:27:39 Router kernel: Neighbour table overflow. > >>> > >>>This is Linux kernel 2.4.18, running linux-atm-2.4.0 with Fore LE155 NICs > >>>using LANE. > >>> > >>>Thanks, > >>> > >>>--- > >>>John Fraizer | High-Security Datacenter Services | > >>>President | Dedicated circuits 64k - 155M OC3 | > >>>EnterZone, Inc | Virtual, Dedicated, Colocation | > >>>http://www.enterzone.net/ | Network Consulting Services | > >>> > > > > > > > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Linux-atm-general mailing list > Linux-atm-general@xxxxxxxxxxxxxxxxxxxxx > https://lists.sourceforge.net/lists/listinfo/linux-atm-general >

Previous Message by Thread: click to view message preview

Re: [PATCH 1/4] Net device error logging, revised

> The following options come to mind: > 1. Keep the msg buffer, but make it smaller. Around 120 bytes would probably > be > big enough for the vast majority of messages. (printk() uses a 1024-byte > buffer, > but it's static -- see #2.) > > 2. Use a big, static buffer, protected by a spinlock. printk() does this. > > 3. Do the whole thing in a macro, as in previous proposals. The size of the > macro > expansion could be reduced somewhat by doing the encode-prefix step in a > function -- > something like: > > #define netdev_printk(sevlevel, netdev, msglevel, format, arg...) \ > do { \ > if (NETIF_MSG_##msglevel == NETIF_MSG_ALL || ((netdev)->msg_enable & > NETIF_MSG_##msglevel)) { \ > char pfx[40]; \ > printk(sevlevel "%s: " format , make_netdev_msg_prefix(pfx, netdev) , > ## arg); \ > }} while (0) > > This would make your code bigger, but not that much bigger for the common > case where > the msglevel is omitted (and the 'if(...)' is optimized out). Is there some way to tack copy and prepend what you want onto the format string, and add additional arguments to the call to printk? That way you wouldn't need space for the potentially large resulting string, but only enough room for the expanded format string.

Next Message by Thread: click to view message preview

route-cache performance

So far things look really good with 2.4.22-rc2 with a 1G Celery and e1000. This is just send-only with full (123K) routes and then a small routing table. Tomorrow I'll test forwarding (in one e1000, out the other). Here's with a full table: 34 e1000_irq_enable 0.7083 67 kmalloc 0.8375 147 memcpy_fromiovecend 0.9187 115 kfree_skbmem 1.0268 103 pfifo_fast_dequeue 1.2875 511 raw_getrawfrag 2.2812 272 __generic_copy_from_user 2.4286 322 handle_IRQ_event 2.8750 203 kfree 3.1719 198 system_call 3.5357 And with < 10 routes: 29 kmalloc 0.3625 45 kfree_skbmem 0.4018 66 memcpy_fromiovecend 0.4125 23 e1000_irq_enable 0.4792 53 pfifo_fast_dequeue 0.6625 256 raw_getrawfrag 1.1429 149 __generic_copy_from_user 1.3304 170 handle_IRQ_event 1.5179 113 kfree 1.7656 115 system_call 2.0536 Juno was able to send ~330kpps, which is pretty decent. From the profiles it looks like every packet sent by juno leads to a kmalloc/kfree. If that interpretation is correct then a fixed skb pool should lead to a significant performance improvement. Ralph Doncaster, IStop.com president 6042147 Canada Inc.