From owner-netdev@oss.sgi.com Sun Jun 2 02:03:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5293dnC002666 for ; Sun, 2 Jun 2002 02:03:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5293dim002665 for netdev-outgoing; Sun, 2 Jun 2002 02:03:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from galileo5.galileo.co.il (pop3.galileo.co.il [199.203.130.130]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5293YnC002662 for ; Sun, 2 Jun 2002 02:03:35 -0700 Received: from galileo.co.il (linux2.galileo.co.il [10.2.40.2]) by galileo.co.il (8.8.5/8.8.5) with ESMTP id MAA20526 for ; Sun, 2 Jun 2002 12:03:49 +0200 (GMT-2) Message-ID: <3CF9DDD0.3080809@galileo.co.il> Date: Sun, 02 Jun 2002 11:56:48 +0300 From: Rabeeh Khoury User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Linux IP stack on kernel 2.4.18 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi All, I'm using kernel 2.4.18 and developing an ethernet network interface driver. I have two problems that if you may consult me how to solve them - 1.. How can I adjust the throttling parameter of the IP stack not to drop any packet ? Meantime the IP stack routes 55k packets/sec and all the other it just drops (I can see them by the result of netif_rx). 2.. Routing jumbo packets through IP stack - I send 9K packets in size and IP stack routes the packets but by sending 1K packets in size ! is this possible ? I tripple checked the device driver on receive and transmit and it's ok. Do you know what is the problem ? Thank you alot, Rabeeh From owner-netdev@oss.sgi.com Sun Jun 2 02:38:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g529cQnC003086 for ; Sun, 2 Jun 2002 02:38:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g529cQ37003085 for netdev-outgoing; Sun, 2 Jun 2002 02:38:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from loewe.cosy.sbg.ac.at (loewe.cosy.sbg.ac.at [141.201.2.12]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g529cNnC003080 for ; Sun, 2 Jun 2002 02:38:23 -0700 Received: from mausmaki.cosy.sbg.ac.at (mausmaki.cosy.sbg.ac.at [141.201.2.18]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with ESMTP id LAA08055; Sun, 2 Jun 2002 11:39:53 +0200 (MET DST) Date: Sun, 2 Jun 2002 11:39:53 +0200 (MET DST) From: "Thomas 'Dent' Mirlacher" To: Rabeeh Khoury cc: netdev@oss.sgi.com Subject: Re: Linux IP stack on kernel 2.4.18 In-Reply-To: <3CF9DDD0.3080809@galileo.co.il> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk --snip/snip > 2.. Routing jumbo packets through IP stack - I send 9K packets in size and IP stack routes the packets but by sending 1K packets in size ! is this possible ? I tripple checked the device driver on receive and transmit and it's ok. Do you know what is the problem ? did you check you MTU? tm -- in some way i do, and in some way i don't. From owner-netdev@oss.sgi.com Sun Jun 2 10:18:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g52HIHnC015498 for ; Sun, 2 Jun 2002 10:18:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g52HIHgm015497 for netdev-outgoing; Sun, 2 Jun 2002 10:18:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from galileo5.galileo.co.il (pop3.galileo.co.il [199.203.130.130]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g52HIAnC015494 for ; Sun, 2 Jun 2002 10:18:12 -0700 Received: from galileo.co.il (linux2.galileo.co.il [10.2.40.2]) by galileo.co.il (8.8.5/8.8.5) with ESMTP id UAA14689; Sun, 2 Jun 2002 20:18:24 +0200 (GMT-2) Message-ID: <3CFA51BA.1000202@galileo.co.il> Date: Sun, 02 Jun 2002 20:11:22 +0300 From: Rabeeh Khoury User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Thomas 'Dent' Mirlacher" CC: netdev@oss.sgi.com Subject: Re: Linux IP stack on kernel 2.4.18 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Thomas 'Dent' Mirlacher wrote: >--snip/snip > > > >>2.. Routing jumbo packets through IP stack - I send 9K packets in size and IP stack routes the packets but by sending 1K packets in size ! is this possible ? I tripple checked the device driver on receive and transmit and it's ok. Do you know what is the problem ? >> >> > >did you check you MTU? > sh-2.04# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 64:41:40:12:12:31 inet addr:10.2.40.130 Bcast:10.2.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:9700 Metric:1 RX packets:5668 errors:0 dropped:0 overruns:0 frame:0 TX packets:3280 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4787563 (4.5 Mb) TX bytes:543741 (530.9 Kb) Interrupt:32 > > tm > > > From owner-netdev@oss.sgi.com Mon Jun 3 01:47:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g538l4nC025015 for ; Mon, 3 Jun 2002 01:47:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g538l40n025014 for netdev-outgoing; Mon, 3 Jun 2002 01:47:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from galileo5.galileo.co.il (pop3.galileo.co.il [199.203.130.130]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g538ksnC025011 for ; Mon, 3 Jun 2002 01:46:56 -0700 Received: from galileo.co.il (linux2.galileo.co.il [10.2.40.2]) by galileo.co.il (8.8.5/8.8.5) with ESMTP id LAA00922; Mon, 3 Jun 2002 11:47:13 +0200 (GMT-2) Message-ID: <3CFB2B6B.90502@galileo.co.il> Date: Mon, 03 Jun 2002 11:40:11 +0300 From: Rabeeh Khoury User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rabeeh Khoury CC: netdev@oss.sgi.com Subject: Re: Linux IP stack on kernel 2.4.18 References: <3CF9DDD0.3080809@galileo.co.il> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk I fixed the problems. I'm replying for the record of the mailing list. Rabeeh Khoury wrote: > Hi All, > > I'm using kernel 2.4.18 and developing an ethernet network interface > driver. > I have two problems that if you may consult me how to solve them - > > 1.. How can I adjust the throttling parameter of the IP stack not to > drop any packet ? Meantime the IP stack routes 55k packets/sec and all > the other it just drops (I can see them by the result of netif_rx). echo 50000 > /proc/sys/net/core/netdev_max_backlog This puts the throttling parameter of the IP stack to 50000, instead of 300 which is the defaul in kernel 2.4.18 (the default is set in net/core/dev.c with the variable 'int netdev_max_backlog = 300;') > > 2.. Routing jumbo packets through IP stack - I send 9K packets in size > and IP stack routes the packets but by sending 1K packets in size ! is > this possible ? I tripple checked the device driver on receive and > transmit and it's ok. Do you know what is the problem ? The HW I'v used that generates jumbo packets has put a wrong total_length field in the IP header, which made IP stack remove a large chunck of the packet. The relevant code that removes the chunck is in net/ipv4/ip_input.c - /* Our transport medium may have padded the buffer out. Now we know it * is IP we can trim to the true length of the frame. * Note this now means skb->len holds ntohs(iph->tot_len). */ if (skb->len > len) { __pskb_trim(skb, len); if (skb->ip_summed == CHECKSUM_HW) skb->ip_summed = CHECKSUM_NONE; } > > > > Thank you alot, > Rabeeh > > > > From owner-netdev@oss.sgi.com Mon Jun 3 08:20:24 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g53FKOnC032747 for ; Mon, 3 Jun 2002 08:20:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53FKOoV032746 for netdev-outgoing; Mon, 3 Jun 2002 08:20:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g53FKKnC032742 for ; Mon, 3 Jun 2002 08:20:21 -0700 Received: (from robert@localhost) by robur.slu.se (8.8.7/8.8.7) id RAA25544; Mon, 3 Jun 2002 17:25:27 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15611.35431.116599.261523@robur.slu.se> Date: Mon, 3 Jun 2002 17:25:27 +0200 To: Rabeeh Khoury Cc: netdev@oss.sgi.com Subject: Linux IP stack on kernel 2.4.18 In-Reply-To: <3CF9DDD0.3080809@galileo.co.il> References: <3CF9DDD0.3080809@galileo.co.il> X-Mailer: VM 6.92 under Emacs 19.34.1 Sender: owner-netdev@oss.sgi.com Precedence: bulk Rabeeh Khoury writes: > > 1.. How can I adjust the throttling parameter of the IP stack not to drop any packet ? Meantime the IP stack routes 55k packets/sec and all the other it just drops (I can see them by the result of netif_rx). Hello! There are no "throttling parameter" you have probably hit some of your machine limits, bandwidth, CPU etc and 55 kpps can be decent. You didn't mention your input rate, paket size or hardware. http://www.cyberus.ca/~hadi/usenix-paper.tgz Discusses related issues.. Cheers. --ro From owner-netdev@oss.sgi.com Tue Jun 4 08:41:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54FfXnC029261 for ; Tue, 4 Jun 2002 08:41:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54FfXDd029260 for netdev-outgoing; Tue, 4 Jun 2002 08:41:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54FfSnC029257 for ; Tue, 4 Jun 2002 08:41:29 -0700 Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 04 Jun 2002 09:43:16 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Tue, 04 Jun 2002 09:44:00 -0600 From: "Ky Srinivasan" To: Subject: neighbor table overflow Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-netdev@oss.sgi.com Precedence: bulk While running Web Polygraph benchmark against a proxy hosted on a Linux system (kernel version: 2.4.18-0.22), we are overflowing the neighbor table - line number 661 in route.c. Is this a known problem. Any help here would be greatly appreciated. K. Y From owner-netdev@oss.sgi.com Thu Jun 6 12:15:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56JFCnC023207 for ; Thu, 6 Jun 2002 12:15:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56JFBb2023206 for netdev-outgoing; Thu, 6 Jun 2002 12:15:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from vieo.com (66-106-235-35.customer.algx.net [66.106.235.35]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56JF2nC023200 for ; Thu, 6 Jun 2002 12:15:03 -0700 Received: (from root@localhost) by vieo.com (8.11.2/8.11.2) id g56JH0A26068 for netdev@oss.sgi.com; Thu, 6 Jun 2002 14:17:00 -0500 (CDT) (envelope-from golio@vieo.com) Received: from vieo.com (golio@[10.3.0.111]) by vieo.com (8.11.2/8.11.2) with ESMTP id g56JGwZ25948; Thu, 6 Jun 2002 14:16:59 -0500 (CDT) (envelope-from golio@vieo.com) Message-ID: <3CFFB4A2.E9FC09FC@vieo.com> Date: Thu, 06 Jun 2002 14:14:42 -0500 From: Joseph Golio Organization: Development X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Thomas 'Dent' Mirlacher" CC: netdev@oss.sgi.com, jeff young , gary klesk Subject: Re: [Fwd: IPoIB] References: X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Thomas 'Dent' Mirlacher wrote: Thomas, Thanks for the reply. The more I dig into this, the more I figure out that the problem is larger than I though. Not only do I need to increase the size of a hardware address, I also need to provide a new interface service routine to allow the device driver to lookup/translate a portion of the hardware address and return more information that needs to go into the ARP cache. Specifically, the IETF IPoIB group has defined an Infiniband hardware address to have 1 byte of reserved, 3 bytes of Queue Pair Number (QPN) and 16 bytes of Global Identifier (GID). Unfortunately, in order to build the hardware header in packets to send, another piece of information is needed -- that being the Local Identifier (LID). If the LID is kept in the ARP cache, then it will be readily available from "arp_find()" at the time of transmission. If we don't do that, we would have to have a separate table and mechanism in the driver to map from QPN/GID ===> LID. I would rather not do that if I didn't have to. It seems fundamental (at least to me) that everything one needs to build the hardware header (at least everything that is related specifically to the destination) should be stored in the ARP cache. Thoughts anyone ? Thanks, Joe > --snip/snip > > > > I have a question. I am working on developing a Linux driver for IP over > > > Infiniband (IPoIB) and > > > have run into an issue that I need your advice. The draft standard from the > > > IETF on IPoIB > > > encapsulation and address resolution over Infiniband networks (see the link > > > below - section 6.1.1) > > > defines the hardware address as being 20 bytes in length. It appears that > > > the "netdevice.h" file in > > > Linux has MAX_ADDR_LEN set to 7 (at least in my version which is SuSe 7.3 - > > for 2.5.18 at least it's set to 8, but there is no reason to not change it to > 20 beside wasting some memory > > n time for > a) broadcast address > b) device address > int netdevice > sum(m[n]) times for the multicast list > > where n == number of network devices, m == number of MC entries per device > as i can see it. > > and this "overhead" should be really acceptable :) > > ... probably you will break some "external" stuff like freeswan, but this > shouldn't be your problem. > > tm > > -- > in some way i do, and in some way i don't. From owner-netdev@oss.sgi.com Thu Jun 6 12:30:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56JUinC023385 for ; Thu, 6 Jun 2002 12:30:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56JUigU023384 for netdev-outgoing; Thu, 6 Jun 2002 12:30:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from loewe.cosy.sbg.ac.at (loewe.cosy.sbg.ac.at [141.201.2.12]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56JUcnC023381 for ; Thu, 6 Jun 2002 12:30:39 -0700 Received: from mausmaki.cosy.sbg.ac.at (mausmaki.cosy.sbg.ac.at [141.201.2.18]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with ESMTP id VAA25716; Thu, 6 Jun 2002 21:32:32 +0200 (MET DST) Date: Thu, 6 Jun 2002 21:32:32 +0200 (MET DST) From: "Thomas 'Dent' Mirlacher" To: Joseph Golio cc: netdev@oss.sgi.com, jeff young , gary klesk Subject: Re: [Fwd: IPoIB] In-Reply-To: <3CFFB4A2.E9FC09FC@vieo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk --snip/snip > The more I dig into this, the more I figure out that the > problem is larger than I though. Not only do I need to increase the size of a > hardware address, I also need to provide a new interface service routine to > allow the device driver to lookup/translate a portion of the hardware address > and return more information that needs to go into the ARP cache. > > Specifically, the IETF IPoIB group has defined an Infiniband hardware > address to have 1 byte of reserved, 3 bytes of Queue Pair Number (QPN) and > 16 bytes of Global Identifier (GID). Unfortunately, in order to build the > hardware header in packets to send, another piece of information is needed > -- that being the Local > Identifier (LID). If the LID is kept in the ARP cache, then it will be readily > available from "arp_find()" at the time of transmission. > If we don't do that, we would have to > have a separate table and mechanism in the driver to map from > QPN/GID ===> LID. > I would rather not do that if I didn't have to. It seems fundamental > (at least to me) that everything one needs to build the hardware header > (at least everything that is related > specifically to the destination) should be stored in the ARP cache. you can already do that, since you will save everything in the arp cache which is the size of dev->addr_len. - did i miss the point? cheers, tm -- in some way i do, and in some way i don't. From owner-netdev@oss.sgi.com Thu Jun 6 12:36:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56JaqnC023516 for ; Thu, 6 Jun 2002 12:36:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56Jaq0t023515 for netdev-outgoing; Thu, 6 Jun 2002 12:36:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56JZanC023508 for ; Thu, 6 Jun 2002 12:35:37 -0700 Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g56JbWb04389; Thu, 6 Jun 2002 15:37:32 -0400 (EDT) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KTYBQR6G; Thu, 6 Jun 2002 15:37:34 -0400 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K4QLRZLS; Thu, 6 Jun 2002 15:37:40 -0400 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 84C705420; Thu, 6 Jun 2002 15:37:28 -0400 (EDT) Message-ID: <3CFFB9F8.54455B6E@nortelnetworks.com> Date: Thu, 06 Jun 2002 15:37:28 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Chris Friesen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: RFC: per-socket statistics on received/dropped packets Content-Type: multipart/mixed; boundary="------------A0F272EED9DE80C6387983F5" Sender: owner-netdev@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------A0F272EED9DE80C6387983F5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit For a while I've been wanting a way for a program to find out if any of its socket buffers were overflowing due to too much incoming traffic. Finally, I decided to code it up and try it out. As it turns out, it was relatively simple to add, although it required the addition of two new entries in sockios.h. Basically, inside of sock_queue_rcv_skb() and sock_queue_err_skb() the receive counter gets incremented unconditionally, and then if there is no free space in the socket buffer then we also increment the counter for messages dropped due to out of memory. The stats are stored as part of a socket_stats struct, making it easy to add other counters in the future. To access and reset the counters, two ioctl commands were added to the socket ioctl. GIOCSOCKSTATS is used to get the stats, while SIOCZEROSOCKSTATS is used to reset them. I haven't bothered with trying to reset them both atomically as I don't think it's that critical. The patch was coded and tested for 2.4.18, but it is known to at least apply (with offsets) on 2.5.20. Feel free to bash on it a bit, once the issues are worked out I'll submit to the appropriate maintainer. Chris -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com --------------A0F272EED9DE80C6387983F5 Content-Type: text/plain; charset=us-ascii; name="sockstats.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sockstats.patch" diff -Nur 2.4.18/include/linux/sockios.h 2.4.18/include/linux/sockios.h --- 2.4.18/include/linux/sockios.h Wed Nov 7 17:39:36 2001 +++ 2.4.18/include/linux/sockios.h Wed Jun 5 15:55:54 2002 @@ -113,6 +113,10 @@ #define SIOCBONDSLAVEINFOQUERY 0x8993 /* rtn info about slave state */ #define SIOCBONDINFOQUERY 0x8994 /* rtn info about bond state */ #define SIOCBONDCHANGEACTIVE 0x8995 /* update to a new active slave */ + +/* per-socket statistics manipulation */ +#define GIOCSOCKSTATS 0x8996 /* get the per-socket statistics */ +#define SIOCZEROSOCKSTATS 0x8997 /* zero out the per-socket statistics */ /* Device private ioctl calls */ diff -Nur 2.4.18/include/net/sock.h 2.4.18/include/net/sock.h --- 2.4.18/include/net/sock.h Thu May 2 15:32:20 2002 +++ 2.4.18/include/net/sock.h Wed Jun 5 15:58:24 2002 @@ -480,6 +480,16 @@ wait_queue_head_t wq; } socket_lock_t; +/* per-socket statistics. received is the total number of skbuffs received + * on that socket. dropped_no_mem is the number of packets dropped due + * to a lack of space on the socket receive buffer + */ +typedef struct { + __u64 received; + __u32 dropped_no_mem; +} socket_stats; + + #define sock_lock_init(__sk) \ do { spin_lock_init(&((__sk)->lock.slock)); \ (__sk)->lock.users = 0; \ @@ -678,6 +688,10 @@ int (*backlog_rcv) (struct sock *sk, struct sk_buff *skb); void (*destruct)(struct sock *sk); + + + /* per-socket statistics */ + socket_stats stats; }; /* The per-socket spinlock must be held here. */ @@ -1145,11 +1159,15 @@ static inline int sock_queue_rcv_skb(struct sock *sk, struct sk_buff *skb) { + sk->stats.received++; + /* Cast skb->rcvbuf to unsigned... It's pointless, but reduces number of warnings when compiling with -W --ANK */ - if (atomic_read(&sk->rmem_alloc) + skb->truesize >= (unsigned)sk->rcvbuf) + if (atomic_read(&sk->rmem_alloc) + skb->truesize >= (unsigned)sk->rcvbuf) { + sk->stats.dropped_no_mem++; return -ENOMEM; + } #ifdef CONFIG_FILTER if (sk->filter) { @@ -1179,11 +1197,16 @@ static inline int sock_queue_err_skb(struct sock *sk, struct sk_buff *skb) { + sk->stats.received++; + /* Cast skb->rcvbuf to unsigned... It's pointless, but reduces number of warnings when compiling with -W --ANK */ - if (atomic_read(&sk->rmem_alloc) + skb->truesize >= (unsigned)sk->rcvbuf) + if (atomic_read(&sk->rmem_alloc) + skb->truesize >= (unsigned)sk->rcvbuf) { + sk->stats.dropped_no_mem++; return -ENOMEM; + } + skb_set_owner_r(skb, sk); skb_queue_tail(&sk->error_queue,skb); if (!sk->dead) diff -Nur 2.4.18/net/core/sock.c 2.4.18/net/core/sock.c --- 2.4.18/net/core/sock.c Fri Dec 21 12:42:05 2001 +++ 2.4.18/net/core/sock.c Wed Jun 5 13:59:37 2002 @@ -1202,6 +1202,9 @@ sk->rcvlowat = 1; sk->rcvtimeo = MAX_SCHEDULE_TIMEOUT; sk->sndtimeo = MAX_SCHEDULE_TIMEOUT; + + sk->stats.received = 0; + sk->stats.dropped_no_mem = 0; atomic_set(&sk->refcnt, 1); } diff -Nur 2.4.18/net/ipv4/af_inet.c 2.4.18/net/ipv4/af_inet.c --- 2.4.18/net/ipv4/af_inet.c Fri Dec 21 12:42:05 2001 +++ 2.4.18/net/ipv4/af_inet.c Wed Jun 5 15:56:20 2002 @@ -834,6 +834,16 @@ int pid; switch(cmd) { + case GIOCSOCKSTATS: + return copy_to_user((void *)arg, &sk->stats, sizeof(sk->stats)); + case SIOCZEROSOCKSTATS: + if (!capable(CAP_NET_ADMIN)) + return -EPERM; + else { + sk->stats.dropped_no_mem = 0; + sk->stats.received = 0; + return (0); + } case FIOSETOWN: case SIOCSPGRP: err = get_user(pid, (int *) arg); --------------A0F272EED9DE80C6387983F5-- From owner-netdev@oss.sgi.com Thu Jun 6 13:00:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56K0JnC024796 for ; Thu, 6 Jun 2002 13:00:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56K0Jp5024795 for netdev-outgoing; Thu, 6 Jun 2002 13:00:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from vieo.com (66-106-235-35.customer.algx.net [66.106.235.35]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56K0AnC024792 for ; Thu, 6 Jun 2002 13:00:10 -0700 Received: (from root@localhost) by vieo.com (8.11.2/8.11.2) id g56K28L56399 for netdev@oss.sgi.com; Thu, 6 Jun 2002 15:02:08 -0500 (CDT) (envelope-from golio@vieo.com) Received: from vieo.com (golio@[10.3.0.111]) by vieo.com (8.11.2/8.11.2) with ESMTP id g56K26Z56280; Thu, 6 Jun 2002 15:02:06 -0500 (CDT) (envelope-from golio@vieo.com) Message-ID: <3CFFBF36.2BF8B884@vieo.com> Date: Thu, 06 Jun 2002 14:59:50 -0500 From: Joseph Golio Organization: Development X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Thomas 'Dent' Mirlacher" CC: netdev@oss.sgi.com, jeff young , gary klesk Subject: Re: [Fwd: IPoIB] References: X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Thomas 'Dent' Mirlacher wrote: > --snip/snip > > > The more I dig into this, the more I figure out that the > > problem is larger than I though. Not only do I need to increase the size of a > > hardware address, I also need to provide a new interface service routine to > > allow the device driver to lookup/translate a portion of the hardware address > > and return more information that needs to go into the ARP cache. > > > > Specifically, the IETF IPoIB group has defined an Infiniband hardware > > address to have 1 byte of reserved, 3 bytes of Queue Pair Number (QPN) and > > 16 bytes of Global Identifier (GID). Unfortunately, in order to build the > > hardware header in packets to send, another piece of information is needed > > -- that being the Local > > Identifier (LID). If the LID is kept in the ARP cache, then it will be readily > > available from "arp_find()" at the time of transmission. > > > If we don't do that, we would have to > > have a separate table and mechanism in the driver to map from > > QPN/GID ===> LID. > > I would rather not do that if I didn't have to. It seems fundamental > > (at least to me) that everything one needs to build the hardware header > > (at least everything that is related > > specifically to the destination) should be stored in the ARP cache. > > you can already do that, since you will save everything in the arp > cache which is the size of dev->addr_len. - did i miss the point? Either you missed the point, I didn't make the point, or I'm missing something... :-) Let me try this again. The IETF has defined the hardware address as having 2 fields. The QPN and GID. Unfortunately, we need a 3rd item to build the headers. The LID. The LID can be gotten by IBTA methods once we know the GID. So, implementations that follow the IETF spec will be setting their local hardware address to their own GID and some QPN. So, when I send out an ARP request and get back an ARP reply, it will have QPN and GID. So, what get's stored in my local ARP cache, if I don't do anything to the ARP code, is simply the QPN/GID value. When I go to send a packet, I will call arp_find() and get back the QPN/GID. What I really need is the LID. SO, either I would have to translate QPN/GID to LID at that time (NOT GOOD), or, back when the ARP reply came in, the ARP code could look at the arp_hrd and see if it's (32) ARPHRD_INFINIBAND and if it is, call an interface service routine to suplement the ARP info before storing it in the cache. I know, it's not pretty, but I'm really struggling here. If I were to do this in the driver, I would have to have some way of knowing that the ARP had completed so that I could then go out and translate the GID to LID and stuff it into a private driver lookup table (hashed probably). Not real crazy about that idea... Joe > > > cheers, > > tm > > -- > in some way i do, and in some way i don't. From owner-netdev@oss.sgi.com Thu Jun 6 15:04:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56M4fnC027640 for ; Thu, 6 Jun 2002 15:04:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56M4fRM027639 for netdev-outgoing; Thu, 6 Jun 2002 15:04:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from balu.sch.bme.hu (balu.sch.bme.hu [152.66.208.40]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56M4anC027634 for ; Thu, 6 Jun 2002 15:04:37 -0700 Received: from localhost.localdomain (kisza@hoi.sch.bme.hu [152.66.213.231]) by balu.sch.bme.hu (8.12.1/8.12.1) with ESMTP id g56M6cXJ016464 for ; Fri, 7 Jun 2002 00:06:38 +0200 (MEST) Subject: [TAHI test evironment request] From: Andras Kis-Szabo To: Netdev Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 07 Jun 2002 00:06:48 +0200 Message-Id: <1023401208.12112.17.camel@hoi> Mime-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi, If You have a few free time and You have got an installed TAHI environment (or you are using extension headers in real environment), please help me with a little test! Please contact me in a private e-mail if you are a volunteer :) (Netfilter-related) Thanks & Reagrds, kisza -- Andras Kis-Szabo Security Development, Design and Audit -------------------------/ Zorp, NetFilter and IPv6 kisza@SecurityAudit.hu /-----Member of the BUTE-MIS-SEARCHlab------> From owner-netdev@oss.sgi.com Thu Jun 6 19:48:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g572mbnC031956 for ; Thu, 6 Jun 2002 19:48:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g572mbbx031955 for netdev-outgoing; Thu, 6 Jun 2002 19:48:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from 21cn.com ([61.140.60.248]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g572mRnC031952 for ; Thu, 6 Jun 2002 19:48:29 -0700 Received: from 21cn.com([10.2.1.2]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm3b3d006597; Fri, 07 Jun 2002 10:58:39 +0800 Received: from oss.sgi.com([128.167.58.27]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm953cfb870a; Mon, 03 Jun 2002 16:47:25 +0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g538mBnC025078; Mon, 3 Jun 2002 01:48:11 -0700 Received: from localhost (mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) with SMTP id g538m9mF025077; Mon, 3 Jun 2002 01:48:09 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Mon, 3 Jun 2002 01:47:05 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g538l4nC025015 for ; Mon, 3 Jun 2002 01:47:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g538l40n025014 for netdev-outgoing; Mon, 3 Jun 2002 01:47:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from galileo5.galileo.co.il (pop3.galileo.co.il [199.203.130.130]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g538ksnC025011 for ; Mon, 3 Jun 2002 01:46:56 -0700 Received: from galileo.co.il (linux2.galileo.co.il [10.2.40.2]) by galileo.co.il (8.8.5/8.8.5) with ESMTP id LAA00922; Mon, 3 Jun 2002 11:47:13 +0200 (GMT-2) Message-ID: <3CFB2B6B.90502@galileo.co.il> Date: Mon, 03 Jun 2002 11:40:11 +0300 From: Rabeeh Khoury User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rabeeh Khoury CC: netdev@oss.sgi.com Subject: Re: Linux IP stack on kernel 2.4.18 References: <3CF9DDD0.3080809@galileo.co.il> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk I fixed the problems. I'm replying for the record of the mailing list. Rabeeh Khoury wrote: > Hi All, > > I'm using kernel 2.4.18 and developing an ethernet network interface > driver. > I have two problems that if you may consult me how to solve them - > > 1.. How can I adjust the throttling parameter of the IP stack not to > drop any packet ? Meantime the IP stack routes 55k packets/sec and all > the other it just drops (I can see them by the result of netif_rx). echo 50000 > /proc/sys/net/core/netdev_max_backlog This puts the throttling parameter of the IP stack to 50000, instead of 300 which is the defaul in kernel 2.4.18 (the default is set in net/core/dev.c with the variable 'int netdev_max_backlog = 300;') > > 2.. Routing jumbo packets through IP stack - I send 9K packets in size > and IP stack routes the packets but by sending 1K packets in size ! is > this possible ? I tripple checked the device driver on receive and > transmit and it's ok. Do you know what is the problem ? The HW I'v used that generates jumbo packets has put a wrong total_length field in the IP header, which made IP stack remove a large chunck of the packet. The relevant code that removes the chunck is in net/ipv4/ip_input.c - /* Our transport medium may have padded the buffer out. Now we know it * is IP we can trim to the true length of the frame. * Note this now means skb->len holds ntohs(iph->tot_len). */ if (skb->len > len) { __pskb_trim(skb, len); if (skb->ip_summed == CHECKSUM_HW) skb->ip_summed = CHECKSUM_NONE; } > > > > Thank you alot, > Rabeeh > > > > From owner-netdev@oss.sgi.com Thu Jun 6 20:22:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g573MenC000392 for ; Thu, 6 Jun 2002 20:22:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g573MdeP000391 for netdev-outgoing; Thu, 6 Jun 2002 20:22:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g573McnC000388 for ; Thu, 6 Jun 2002 20:22:38 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id UAA18817; Thu, 6 Jun 2002 20:21:09 -0700 Date: Thu, 06 Jun 2002 20:21:08 -0700 (PDT) Message-Id: <20020606.202108.52904668.davem@redhat.com> To: cfriesen@nortelnetworks.com Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: RFC: per-socket statistics on received/dropped packets From: "David S. Miller" In-Reply-To: <3CFFB9F8.54455B6E@nortelnetworks.com> References: <3CFFB9F8.54455B6E@nortelnetworks.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Your idea is totally useless for non-datagram sockets. Only datagram sockets use the interfaces where you bump the counters. I don't like the patch, nor the idea behind it, at all. From owner-netdev@oss.sgi.com Fri Jun 7 08:33:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57FXinC013184 for ; Fri, 7 Jun 2002 08:33:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57FXiUx013183 for netdev-outgoing; Fri, 7 Jun 2002 08:33:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57FWhnC013176 for ; Fri, 7 Jun 2002 08:32:43 -0700 Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g57FYgu09687; Fri, 7 Jun 2002 11:34:42 -0400 (EDT) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KWNBACWL; Fri, 7 Jun 2002 11:34:38 -0400 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K4QLR6HT; Fri, 7 Jun 2002 11:34:38 -0400 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 68579541E; Fri, 7 Jun 2002 11:34:35 -0400 (EDT) Message-ID: <3D00D28B.BAC57EC@nortelnetworks.com> Date: Fri, 07 Jun 2002 11:34:35 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Chris Friesen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: RFC: per-socket statistics on received/dropped packets References: <3CFFB9F8.54455B6E@nortelnetworks.com> <20020606.202108.52904668.davem@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk "David S. Miller" wrote: > > Your idea is totally useless for non-datagram sockets. > Only datagram sockets use the interfaces where you bump > the counters. > > I don't like the patch, nor the idea behind it, at all. Thanks for the feedback. I buy the point about it only making sense for datagram sockets in its current form. Thus it would maybe make more sense to use udp_ioctl() rather than in the generic socket ioctl. However, what do you have against the basic idea of a program knowing how many packets have been dropped on its sockets? I added the feature to try and figure out where packets were being dropped in an app I am developing, and so far its been very useful. More generally, is there a generic place that I could tie into for the counter increment that would work for all sockets? While tcp would automatically handle the dropped packets, it might be useful to know how many there were. Thanks, Chris -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com From owner-netdev@oss.sgi.com Sat Jun 8 13:26:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g58KQunC005394 for ; Sat, 8 Jun 2002 13:26:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g58KQtPO005393 for netdev-outgoing; Sat, 8 Jun 2002 13:26:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from grok.yi.org (IDENT:0NqoDuOgJOQK0z4RJ4OGyaJfxl98ym7O@ip68-3-14-32.ph.ph.cox.net [68.3.14.32]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g58KQmnC005389 for ; Sat, 8 Jun 2002 13:26:51 -0700 Received: from candelatech.com (IDENT:JaEMxSAO6BisvUBXHTrBV+cR/OdfN996@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g57MFOL18187; Fri, 7 Jun 2002 15:15:24 -0700 Message-ID: <3D01307C.4090503@candelatech.com> Date: Fri, 07 Jun 2002 15:15:24 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: "David S. Miller" CC: cfriesen@nortelnetworks.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: RFC: per-socket statistics on received/dropped packets References: <3CFFB9F8.54455B6E@nortelnetworks.com> <20020606.202108.52904668.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Datagram sockets are the ones that drop data though (tcp will deal with it via re-transmits). I have not looked at his patch in detail, but I would welcome anything that gets us closer to being able to account for every packet that enters the NIC, or enters the kernel from user-space via send(to), etc... David S. Miller wrote: > Your idea is totally useless for non-datagram sockets. > Only datagram sockets use the interfaces where you bump > the counters. > > I don't like the patch, nor the idea behind it, at all. > > -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From owner-netdev@oss.sgi.com Sat Jun 8 14:09:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g58L9BnC005718 for ; Sat, 8 Jun 2002 14:09:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g58L9A1i005717 for netdev-outgoing; Sat, 8 Jun 2002 14:09:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from mark.mielke.cc (IDENT:kKbxPiUE4nK1z5P1dCfI07+YhUd3/E16@mark.mielke.cc [216.209.85.42]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g58L95nC005714 for ; Sat, 8 Jun 2002 14:09:05 -0700 Received: (from mark@localhost) by mark.mielke.cc (8.11.6/8.11.6) id g58L5Bn27747; Sat, 8 Jun 2002 17:05:11 -0400 Date: Sat, 8 Jun 2002 17:05:11 -0400 From: Mark Mielke To: Ben Greear Cc: "David S. Miller" , cfriesen@nortelnetworks.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: RFC: per-socket statistics on received/dropped packets Message-ID: <20020608170511.B26821@mark.mielke.cc> References: <3CFFB9F8.54455B6E@nortelnetworks.com> <20020606.202108.52904668.davem@redhat.com> <3D01307C.4090503@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D01307C.4090503@candelatech.com>; from greearb@candelatech.com on Fri, Jun 07, 2002 at 03:15:24PM -0700 Sender: owner-netdev@oss.sgi.com Precedence: bulk On Fri, Jun 07, 2002 at 03:15:24PM -0700, Ben Greear wrote: > David S. Miller wrote: > > Your idea is totally useless for non-datagram sockets. > > Only datagram sockets use the interfaces where you bump > > the counters. > > I don't like the patch, nor the idea behind it, at all. > Datagram sockets are the ones that drop data though (tcp will > deal with it via re-transmits). Outside of the specific changes suggested by Chris, I can see a requirement to be able to detect poor connections. While TCP/IP may not drop packets from the perspective of user space applications, TCP/IP packets do get lost. For certain applications that require high bandwidth, or low latency, applications may be able to optimize code paths by analyzing statistics related to the socket. Datagram sockets are more straight forward to implement this for, but that does not mean that TCP/IP does not have similar potential. I am not certain what the exact requirement is for in Chris' cases, but I do know that in his field, he is writing something far more complicated and resource intensive than a telnet server. mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From owner-netdev@oss.sgi.com Sat Jun 8 16:05:50 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g58N5onC006443 for ; Sat, 8 Jun 2002 16:05:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g58N5nsB006442 for netdev-outgoing; Sat, 8 Jun 2002 16:05:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g58N5lnC006439 for ; Sat, 8 Jun 2002 16:05:48 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id QAA27079; Sat, 8 Jun 2002 16:04:07 -0700 Date: Sat, 08 Jun 2002 16:04:07 -0700 (PDT) Message-Id: <20020608.160407.101346167.davem@redhat.com> To: mark@mark.mielke.cc Cc: greearb@candelatech.com, cfriesen@nortelnetworks.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: RFC: per-socket statistics on received/dropped packets From: "David S. Miller" In-Reply-To: <20020608170511.B26821@mark.mielke.cc> References: <20020606.202108.52904668.davem@redhat.com> <3D01307C.4090503@candelatech.com> <20020608170511.B26821@mark.mielke.cc> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk You guys we have SNMP statistics for these events, there is no reason to have them per-socket. You cannot convince me that when you are diagnosing a problem the SNMP stats are not enough to show you if the packets are being dropped. If not, this means we need to add more SNMP events, that is all it means. From owner-netdev@oss.sgi.com Sat Jun 8 17:11:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g590BcnC006811 for ; Sat, 8 Jun 2002 17:11:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g590BbEs006810 for netdev-outgoing; Sat, 8 Jun 2002 17:11:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from grok.yi.org (IDENT:wlRRCx09wsL5A+bvGQg1TnmyW4vBhTnd@ip68-3-14-32.ph.ph.cox.net [68.3.14.32]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g590BVnC006807 for ; Sat, 8 Jun 2002 17:11:32 -0700 Received: from candelatech.com (IDENT:hx5YX2Xbs1YokncpJbyxQcetkeOw8QS+@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g590DZL29223; Sat, 8 Jun 2002 17:13:35 -0700 Message-ID: <3D029DAF.5040006@candelatech.com> Date: Sat, 08 Jun 2002 17:13:35 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: "David S. Miller" CC: mark@mark.mielke.cc, cfriesen@nortelnetworks.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: RFC: per-socket statistics on received/dropped packets References: <20020606.202108.52904668.davem@redhat.com> <3D01307C.4090503@candelatech.com> <20020608170511.B26821@mark.mielke.cc> <20020608.160407.101346167.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk David S. Miller wrote: > You guys we have SNMP statistics for these events, there > is no reason to have them per-socket. You cannot convince > me that when you are diagnosing a problem the SNMP stats > are not enough to show you if the packets are being dropped. So, I will not attempt to convince you that you need per-socket counters. I do know for absolute certain that I would like to have them (I write a traffic-generation & testing program). For instance, when I run 50Mbps bi-directional on a P-4 1.6Ghz machine, using a single port of a DFE-570tx NIC, then I drop around .2% of the packets, in bursts. I have kernel buffers very large (2MB), and the CPU is not maxed out. With the current system, it is difficult for me to know exactly what I need to change to get better performance and/or if better performance is even possible. > If not, this means we need to add more SNMP events, that is > all it means. If you're talking per-socket SNMP counters, then that could work. General protocol-wide counters would not help much, at least in my case. Thanks, Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From owner-netdev@oss.sgi.com Sat Jun 8 17:52:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g590qpnC007152 for ; Sat, 8 Jun 2002 17:52:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g590qpU4007151 for netdev-outgoing; Sat, 8 Jun 2002 17:52:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g590qmnC007148 for ; Sat, 8 Jun 2002 17:52:48 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id RAA27573; Sat, 8 Jun 2002 17:51:08 -0700 Date: Sat, 08 Jun 2002 17:51:08 -0700 (PDT) Message-Id: <20020608.175108.84748597.davem@redhat.com> To: greearb@candelatech.com Cc: mark@mark.mielke.cc, cfriesen@nortelnetworks.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: RFC: per-socket statistics on received/dropped packets From: "David S. Miller" In-Reply-To: <3D029DAF.5040006@candelatech.com> References: <20020608170511.B26821@mark.mielke.cc> <20020608.160407.101346167.davem@redhat.com> <3D029DAF.5040006@candelatech.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk From: Ben Greear Date: Sat, 08 Jun 2002 17:13:35 -0700 If you're talking per-socket SNMP counters, then that could work. General protocol-wide counters would not help much, at least in my case. Why not? If you know where the drops are occurring, what else do you need to know? I'm not talking about per-socket SNMP counters, that would be rediclious. From owner-netdev@oss.sgi.com Sun Jun 9 07:46:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g59Ek1nC016905 for ; Sun, 9 Jun 2002 07:46:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g59Ek1rb016904 for netdev-outgoing; Sun, 9 Jun 2002 07:46:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from evil.netppl.fi (evil.netppl.fi [195.242.209.201]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g59EjrnC016901 for ; Sun, 9 Jun 2002 07:45:54 -0700 Received: (from pp@localhost) by evil.netppl.fi (8.11.6/8.11.6) id g59Elep08823; Sun, 9 Jun 2002 17:47:40 +0300 Date: Sun, 9 Jun 2002 17:47:40 +0300 From: Pekka =?iso-8859-15?Q?Pietik=E4inen?= To: Mark Mielke Cc: Ben Greear , "David S. Miller" , cfriesen@nortelnetworks.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: RFC: per-socket statistics on received/dropped packets Message-ID: <20020609144740.GA7805@netppl.fi> References: <3CFFB9F8.54455B6E@nortelnetworks.com> <20020606.202108.52904668.davem@redhat.com> <3D01307C.4090503@candelatech.com> <20020608170511.B26821@mark.mielke.cc> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20020608170511.B26821@mark.mielke.cc> User-Agent: Mutt/1.4i Sender: owner-netdev@oss.sgi.com Precedence: bulk On Sat, Jun 08, 2002 at 05:05:11PM -0400, Mark Mielke wrote: > Datagram sockets are more straight forward to implement this for, but > that does not mean that TCP/IP does not have similar potential. > > I am not certain what the exact requirement is for in Chris' cases, > but I do know that in his field, he is writing something far more > complicated and resource intensive than a telnet server. Have you guys checked out if the TCP_INFO getsockopt() would work for your needs? (obviously, it'll only work for TCP connections ). It gives you quite a bit of detail about what's happening in your TCP connection (retransmissions, window sizes etc.). printf("unacked: %d sacked: %d lost: %d retrans: %d fackets: %d\n", info.tcpi_unacked,info.tcpi_sacked,info.tcpi_lost, info.tcpi_retrans,info.tcpi_fackets); printf("pmtu: %d rcv_ssthresh: %d rtt: %d rttvar: %d snd_ssthresh: %d\nsnd_cwnd: %d advmss: %d reordering: %d\n",info.tcpi_pmtu,info.tcpi_rcv_ssthresh, info.tcpi_rtt,info.tcpi_rttvar,info.tcpi_snd_ssthresh,info.tcpi_snd_cwnd,info.tcpi_advmss, info.tcpi_reordering); -- M.Sc. (Eng.) Pekka Pietikainen, Nixu Oy From owner-netdev@oss.sgi.com Sun Jun 9 08:00:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g59F0ZnC017112 for ; Sun, 9 Jun 2002 08:00:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g59F0ZCS017111 for netdev-outgoing; Sun, 9 Jun 2002 08:00:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from hawkeye.luckynet.adm (p50887457.dip.t-dialin.net [80.136.116.87]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g59F0TnC017108 for ; Sun, 9 Jun 2002 08:00:30 -0700 Received: from hawkeye.luckynet.adm (hawkeye.luckynet.adm [192.168.1.1]) by hawkeye.luckynet.adm (8.12.1/8.12.1) with ESMTP id g59F2hb5026575; Sun, 9 Jun 2002 09:02:43 -0600 Date: Sun, 9 Jun 2002 09:02:43 -0600 (MDT) From: Lightweight patch manager X-X-Sender: patch@hawkeye.luckynet.adm To: Linux Network cc: Linux Networking Team Subject: [PATCH][2.5] list_move_tail for network core (1 occ) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk This uses the newly introduced list_move_tail macro in net/core/dev.c --- linus-2.5/net/core/dev.c Sun Jun 9 04:17:32 2002 +++ thunder-2.5/net/core/dev.c Sun Jun 9 07:41:55 2002 @@ -1596,8 +1596,7 @@ if (dev->quota <= 0 || dev->poll(dev, &budget)) { local_irq_disable(); - list_del(&dev->poll_list); - list_add_tail(&dev->poll_list, &queue->poll_list); + list_move_tail(&dev->poll_list, &queue->poll_list); if (dev->quota < 0) dev->quota += dev->weight; else -- Lightweight patch manager using pine. If you have any objections, tell me. From owner-netdev@oss.sgi.com Sun Jun 9 08:02:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g59F2CnC017225 for ; Sun, 9 Jun 2002 08:02:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g59F2Br0017224 for netdev-outgoing; Sun, 9 Jun 2002 08:02:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from hawkeye.luckynet.adm (p50887457.dip.t-dialin.net [80.136.116.87]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g59F22nC017221 for ; Sun, 9 Jun 2002 08:02:06 -0700 Received: from hawkeye.luckynet.adm (hawkeye.luckynet.adm [192.168.1.1]) by hawkeye.luckynet.adm (8.12.1/8.12.1) with ESMTP id g59F4Fb5026591; Sun, 9 Jun 2002 09:04:15 -0600 Date: Sun, 9 Jun 2002 09:04:15 -0600 (MDT) From: Lightweight patch manager X-X-Sender: patch@hawkeye.luckynet.adm To: Linux Network cc: Linux Networking Team Subject: [PATCH][2.5] list_move_tail for sunrpc (1 occ) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk This patch introduces the new list_move_tail macro for the sunrpc driver (net/sunrpc/svcsock.c) --- linus-2.5/net/sunrpc/svcsock.c Sun Jun 9 04:17:42 2002 +++ thunder-2.5/net/sunrpc/svcsock.c Sun Jun 9 07:43:53 2002 @@ -1065,8 +1065,7 @@ if (test_bit(SK_TEMP, &svsk->sk_flags)) { /* push active sockets to end of list */ spin_lock_bh(&serv->sv_lock); - list_del(&svsk->sk_list); - list_add_tail(&svsk->sk_list, &serv->sv_tempsocks); + list_move_tail(&svsk->sk_list, &serv->sv_tempsocks); spin_unlock_bh(&serv->sv_lock); } -- Lightweight patch manager using pine. If you have any objections, tell me. From owner-netdev@oss.sgi.com Sun Jun 9 09:15:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g59GF5nC017741 for ; Sun, 9 Jun 2002 09:15:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g59GF57r017740 for netdev-outgoing; Sun, 9 Jun 2002 09:15:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from loewe.cosy.sbg.ac.at (loewe.cosy.sbg.ac.at [141.201.2.12]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g59GE7nC017734 for ; Sun, 9 Jun 2002 09:14:07 -0700 Received: from mausmaki.cosy.sbg.ac.at (mausmaki.cosy.sbg.ac.at [141.201.2.18]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with ESMTP id SAA28982; Sun, 9 Jun 2002 18:16:18 +0200 (MET DST) Date: Sun, 9 Jun 2002 18:16:18 +0200 (MET DST) From: "Thomas 'Dent' Mirlacher" To: ak@muc.de, "David S. Miller" , kuznet@ms2.inr.ac.ru cc: netdev@oss.sgi.com Subject: [PATCH][2.5] net/core/dev.c readability cleanups Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-457399677-1023639378=:16392" Sender: owner-netdev@oss.sgi.com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-457399677-1023639378=:16392 Content-Type: TEXT/PLAIN; charset=US-ASCII hi, the following patch does: o improve readability (by adding _deliver_to_proto, which encapsulates the call for deliver_to_old ones) o clean up types for cpu (cpu should be unsigned int) o nicer use of smp_processor_id() (just call it once, at the beginning of a function) o add functions (_queue_unthrottle, _queue_throttle) o changes the "optimized" version of netif_rx back to the "nomalized" version. (the "normalized" is readable at the first glimpse, plus gcc3 (didn't check it with 2.9*), produces the optimized output anyways) please apply, tm -- in some way i do, and in some way i don't. ---559023410-457399677-1023639378=:16392 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="net_dev.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="net_dev.patch" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBwYXRjaCBmb3IgdGhl IGZvbGxvd2luZyBwcm9qZWN0Og0KIyBQcm9qZWN0IE5hbWU6IExpbnV4IGtl cm5lbCB0cmVlDQojIFRoaXMgcGF0Y2ggZm9ybWF0IGlzIGludGVuZGVkIGZv ciBHTlUgcGF0Y2ggY29tbWFuZCB2ZXJzaW9uIDIuNSBvciBoaWdoZXIuDQoj IFRoaXMgcGF0Y2ggaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBkZWx0YXM6DQoj CSAgICAgICAgICAgQ2hhbmdlU2V0CTEuNDg4ICAgLT4gMS40ODkgIA0KIwlk cml2ZXJzL3ZpZGVvL25lb2ZiLmMJMS4xMiAgICAtPiAxLjEzICAgDQojCSAg ICAgIG5ldC9jb3JlL2Rldi5jCTEuMzIgICAgLT4gMS4zNCAgIA0KIw0KIyBU aGUgZm9sbG93aW5nIGlzIHRoZSBCaXRLZWVwZXIgQ2hhbmdlU2V0IExvZw0K IyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KIyAwMi8wNi8wOQlkZW50QGFpci5tZXRhbm9kZS5vcmcJMS40ODkNCiMg TWVyZ2UgYWlyLm1ldGFub2RlLm9yZzovbW50Ly5kYXRhL2RhdGEvYmsvbGlu dXgtMi41DQojIGludG8gYWlyLm1ldGFub2RlLm9yZzovbW50Ly5kYXRhL2Rh dGEvYmsvbGludXgtcGF0Y2gtbmV0X2NsZWFudXANCiMgLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiMNCmRpZmYgLU5y dSBhL25ldC9jb3JlL2Rldi5jIGIvbmV0L2NvcmUvZGV2LmMNCi0tLSBhL25l dC9jb3JlL2Rldi5jCVN1biBKdW4gIDkgMjM6MDM6MzMgMjAwMg0KKysrIGIv bmV0L2NvcmUvZGV2LmMJU3VuIEp1biAgOSAyMzowMzozMyAyMDAyDQpAQCAt MTA4LDExICsxMDgsNjUgQEANCiAjaWYgZGVmaW5lZChDT05GSUdfTkVUX1JB RElPKSB8fCBkZWZpbmVkKENPTkZJR19ORVRfUENNQ0lBX1JBRElPKQ0KICNp bmNsdWRlIDxsaW51eC93aXJlbGVzcy5oPgkJLyogTm90ZSA6IHdpbGwgZGVm aW5lIFdJUkVMRVNTX0VYVCAqLw0KICNpbmNsdWRlIDxuZXQvaXdfaGFuZGxl ci5oPg0KLSNlbmRpZgkvKiBDT05GSUdfTkVUX1JBRElPIHx8IENPTkZJR19O RVRfUENNQ0lBX1JBRElPICovDQotI2lmZGVmIENPTkZJR19QTElQDQotZXh0 ZXJuIGludCBwbGlwX2luaXQodm9pZCk7DQogI2VuZGlmDQogDQorI2RlZmlu ZSBTVVBQT1JUXzJfMl9QUk9UTyAxDQorDQorI2lmIFNVUFBPUlRfMl8yX1BS T1RPDQorLyoNCisgKiBEZWxpdmVyIHNrYiB0byBhbiBvbGQgcHJvdG9jb2ws IHdoaWNoIGlzIG5vdCB0aHJlYWRlZCB3ZWxsDQorICogb3Igd2hpY2ggZG8g bm90IHVuZGVyc3RhbmQgc2hhcmVkIHNrYnMuDQorICovDQorc3RhdGljIGlu dCBfZGVsaXZlcl90b19vbGRfb25lcyhzdHJ1Y3QgcGFja2V0X3R5cGUgKnB0 LCBzdHJ1Y3Qgc2tfYnVmZiAqc2tiLCBpbnQgbGFzdCkNCit7DQorCXN0YXRp YyBzcGlubG9ja190IG5ldF9iaF9sb2NrID0gU1BJTl9MT0NLX1VOTE9DS0VE Ow0KKwlpbnQgcmV0ID0gTkVUX1JYX0RST1A7DQorDQorCWlmICghbGFzdCkg ew0KKwkJc2tiID0gc2tiX2Nsb25lKHNrYiwgR0ZQX0FUT01JQyk7DQorCQlp ZiAoIXNrYikNCisJCQlyZXR1cm4gcmV0Ow0KKwl9DQorCWlmIChza2JfaXNf bm9ubGluZWFyKHNrYikgJiYgc2tiX2xpbmVhcml6ZShza2IsIEdGUF9BVE9N SUMpICE9IDApIHsNCisJCWtmcmVlX3NrYihza2IpOw0KKwkJCXJldHVybiBy ZXQ7DQorCX0NCisNCisJLyogVGhlIGFzc3VtcHRpb24gKGNvcnJlY3Qgb25l KSBpcyB0aGF0IG9sZCBwcm90b2NvbHMNCisJZGlkIG5vdCBkZXBlbmVkIG9u IEJIcyBkaWZmZXJlbnQgb2YgTkVUX0JIIGFuZCBUSU1FUl9CSC4NCisJKi8N CisNCisJLyogRW11bGF0ZSBORVRfQkggd2l0aCBzcGVjaWFsIHNwaW5sb2Nr ICovDQorCXNwaW5fbG9jaygmbmV0X2JoX2xvY2spOw0KKw0KKwkvKiBEaXNh YmxlIHRpbWVycyBhbmQgd2FpdCBmb3IgYWxsIHRpbWVycyBjb21wbGV0aW9u ICovDQorCXRhc2tsZXRfZGlzYWJsZShiaF90YXNrX3ZlYyArIFRJTUVSX0JI KTsNCisNCisJcmV0ID0gcHQtPmZ1bmMoc2tiLCBza2ItPmRldiwgcHQpOw0K Kw0KKwl0YXNrbGV0X2hpX2VuYWJsZShiaF90YXNrX3ZlYyArIFRJTUVSX0JI KTsNCisJc3Bpbl91bmxvY2soJm5ldF9iaF9sb2NrKTsNCisNCisJcmV0dXJu IHJldDsNCit9DQorI2VuZGlmDQorDQorc3RhdGljIGlubGluZSBpbnQgX2Rl bGl2ZXJfdG9fcHJvdG8oc3RydWN0IHNrX2J1ZmYgKnNrYiwgc3RydWN0IHBh Y2tldF90eXBlICpwdCwgaW50IGlzX2xhc3QpDQorew0KKyNpZiBTVVBQT1JU XzJfMl9QUk9UTw0KKwlpZiAoIXB0LT5kYXRhKSB7DQorCQlyZXR1cm4gX2Rl bGl2ZXJfdG9fb2xkX29uZXMocHQsIHNrYiwgaXNfbGFzdCk7DQorCX0gZWxz ZSB7DQorI2VuZGlmDQorCWlmICghaXNfbGFzdCkNCisJCXNrYiA9IHNrYl9n ZXQoc2tiKTsNCisJCXJldHVybiBwdC0+ZnVuYyhza2IsIHNrYi0+ZGV2LCBw dCk7DQorI2lmIFNVUFBPUlRfMl8yX1BST1RPDQorCX0NCisjZW5kaWYNCisN CisJcmV0dXJuIDA7DQorfQ0KIA0KIC8qIFRoaXMgZGVmaW5lLCBpZiBzZXQs IHdpbGwgcmFuZG9tbHkgZHJvcCBhIHBhY2tldCB3aGVuIGNvbmdlc3Rpb24N CiAgKiBpcyBtb3JlIHRoYW4gbW9kZXJhdGUuICBJdCBoZWxwcyBmYWlybmVz cyBpbiB0aGUgbXVsdGktaW50ZXJmYWNlDQpAQCAtMTMwLDEzICsxODQsMTMg QEANCiBORVRfUFJPRklMRV9ERUZJTkUoc29mdG5ldF9wcm9jZXNzKQ0KIA0K IGNvbnN0IGNoYXIgKmlmX3BvcnRfdGV4dFtdID0gew0KLSAgInVua25vd24i LA0KLSAgIkJOQyIsDQotICAiMTBiYXNlVCIsDQotICAiQVVJIiwNCi0gICIx MDBiYXNlVCIsDQotICAiMTAwYmFzZVRYIiwNCi0gICIxMDBiYXNlRlgiDQor CSJ1bmtub3duIiwNCisJIkJOQyIsDQorCSIxMGJhc2VUIiwNCisJIkFVSSIs DQorCSIxMDBiYXNlVCIsDQorCSIxMDBiYXNlVFgiLA0KKwkiMTAwYmFzZUZY Ig0KIH07DQogDQogLyoNCkBAIC0xNzgsNyArMjMyLDcgQEANCiAjaWZkZWYg Q09ORklHX0hPVFBMVUcNCiBzdGF0aWMgaW50IG5ldF9ydW5fc2Jpbl9ob3Rw bHVnKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIGNoYXIgKmFjdGlvbik7DQog I2Vsc2UNCi0jZGVmaW5lIG5ldF9ydW5fc2Jpbl9ob3RwbHVnKGRldiwgYWN0 aW9uKSAoeyAwOyB9KQ0KKyNkZWZpbmUgbmV0X3J1bl9zYmluX2hvdHBsdWco ZGV2LCBhY3Rpb24pCSgwKQ0KICNlbmRpZg0KIA0KIC8qDQpAQCAtMjkzLDcg KzM0Nyw3IEBADQogCQkJZ290byBvdXQ7DQogCQl9DQogCX0NCi0JcHJpbnRr KEtFUk5fV0FSTklORyAiZGV2X3JlbW92ZV9wYWNrOiAlcCBub3QgZm91bmQu XG4iLCBwdCk7DQorCXByaW50ayhLRVJOX1dBUk5JTkcgIiVwIG5vdCBmb3Vu ZC5cbiIsIHB0KTsNCiBvdXQ6DQogCWJyX3dyaXRlX3VubG9ja19iaChCUl9O RVRQUk9UT19MT0NLKTsNCiB9DQpAQCAtNjU1LDggKzcwOSw4IEBADQogDQog c3RhdGljIGludCBkZWZhdWx0X3JlYnVpbGRfaGVhZGVyKHN0cnVjdCBza19i dWZmICpza2IpDQogew0KLQlwcmludGsoS0VSTl9ERUJVRyAiJXM6IGRlZmF1 bHRfcmVidWlsZF9oZWFkZXIgY2FsbGVkIC0tIEJVRyFcbiIsDQotCSAgICAg ICBza2ItPmRldiA/IHNrYi0+ZGV2LT5uYW1lIDogIk5VTEwhISEiKTsNCisJ cHJpbnRrKEtFUk5fV0FSTklORyAiJXM6IGNhbGxlZCBmb3IgZGV2aWNlICVz IC0tIEJVRyFcbiIsDQorCSAgICAgICBfX2Z1bmNfXywgc2tiLT5kZXYgPyBz a2ItPmRldi0+bmFtZSA6ICJOVUxMISEhIik7DQogCWtmcmVlX3NrYihza2Ip Ow0KIAlyZXR1cm4gMTsNCiB9DQpAQCAtOTAyLDkgKzk1NiwxMCBAQA0KIAkJ CWlmIChza2IyLT5uaC5yYXcgPCBza2IyLT5kYXRhIHx8DQogCQkJICAgIHNr YjItPm5oLnJhdyA+IHNrYjItPnRhaWwpIHsNCiAJCQkJaWYgKG5ldF9yYXRl bGltaXQoKSkNCi0JCQkJCXByaW50ayhLRVJOX0RFQlVHICJwcm90b2NvbCAl MDR4IGlzICINCi0JCQkJCQkJICAiYnVnZ3ksIGRldiAlc1xuIiwNCi0JCQkJ CSAgICAgICBza2IyLT5wcm90b2NvbCwgZGV2LT5uYW1lKTsNCisJCQkJCXBy aW50ayhLRVJOX0RFQlVHICIlczogcHJvdG9jb2wgJTA0eCAiDQorCQkJCQkJ CSAgImlzIGJ1Z2d5LCBkZXYgJXNcbiIsDQorCQkJCQkgICAgICAgX19mdW5j X18sIHNrYjItPnByb3RvY29sLA0KKwkJCQkJICAgICAgIGRldi0+bmFtZSk7 DQogCQkJCXNrYjItPm5oLnJhdyA9IHNrYjItPmRhdGE7DQogCQkJfQ0KIA0K QEAgLTEwMzMsNyArMTA4OCw3IEBADQogCSAgIEVpdGhlciBzaG90IG5vcXVl dWUgcWRpc2MsIGl0IGlzIGV2ZW4gc2ltcGxlciA4KQ0KIAkgKi8NCiAJaWYg KGRldi0+ZmxhZ3MgJiBJRkZfVVApIHsNCi0JCWludCBjcHUgPSBzbXBfcHJv Y2Vzc29yX2lkKCk7DQorCQl1aW50IGNwdSA9IHNtcF9wcm9jZXNzb3JfaWQo KTsNCiANCiAJCWlmIChkZXYtPnhtaXRfbG9ja19vd25lciAhPSBjcHUpIHsN CiAJCQkvKg0KQEAgLTEwNjAsMTUgKzExMTUsMTcgQEANCiAJCQlkZXYtPnht aXRfbG9ja19vd25lciA9IC0xOw0KIAkJCXNwaW5fdW5sb2NrX2JoKCZkZXYt PnhtaXRfbG9jayk7DQogCQkJaWYgKG5ldF9yYXRlbGltaXQoKSkNCi0JCQkJ cHJpbnRrKEtFUk5fREVCVUcgIlZpcnR1YWwgZGV2aWNlICVzIGFza3MgdG8g Ig0KLQkJCQkgICAgICAgInF1ZXVlIHBhY2tldCFcbiIsIGRldi0+bmFtZSk7 DQorCQkJCXByaW50ayhLRVJOX0RFQlVHICIlczogVmlydHVhbCBkZXZpY2Ug JXMgYXNrcyAiDQorCQkJCSAgICAgICAidG8gcXVldWUgcGFja2V0IVxuIiwN CisJCQkJICAgICAgIF9fZnVuY19fLCBkZXYtPm5hbWUpOw0KIAkJCWdvdG8g b3V0X2VuZXRkb3duOw0KIAkJfSBlbHNlIHsNCiAJCQkvKiBSZWN1cnNpb24g aXMgZGV0ZWN0ZWQhIEl0IGlzIHBvc3NpYmxlLA0KIAkJCSAqIHVuZm9ydHVu YXRlbHkgKi8NCiAJCQlpZiAobmV0X3JhdGVsaW1pdCgpKQ0KLQkJCQlwcmlu dGsoS0VSTl9ERUJVRyAiRGVhZCBsb29wIG9uIHZpcnR1YWwgZGV2aWNlICIN Ci0JCQkJICAgICAgICIlcywgZml4IGl0IHVyZ2VudGx5IVxuIiwgZGV2LT5u YW1lKTsNCisJCQkJcHJpbnRrKEtFUk5fREVCVUcgIiVzOiBEZWFkIGxvb3Ag b24gdmlydHVhbCAiDQorCQkJCSAgICAgICAiZGV2aWNlICVzLCBmaXggaXQg dXJnZW50bHkhXG4iLA0KKwkJCQkgICAgICAgX19mdW5jX18sIGRldi0+bmFt ZSk7DQogCQl9DQogCX0NCiAJc3Bpbl91bmxvY2tfYmgoJmRldi0+cXVldWVf bG9jayk7DQpAQCAtMTE1OSw0OCArMTIxNiw0OCBAQA0KIH0NCiAjZW5kaWYN CiANCi1zdGF0aWMgdm9pZCBnZXRfc2FtcGxlX3N0YXRzKGludCBjcHUpDQor c3RhdGljIHZvaWQgZ2V0X3NhbXBsZV9zdGF0cyh1aW50IGNwdSkNCiB7DQor CXN0cnVjdCBzb2Z0bmV0X2RhdGEgKnF1ZXVlID0gJnNvZnRuZXRfZGF0YVtj cHVdOw0KICNpZmRlZiBSQU5EX0xJRQ0KIAl1bnNpZ25lZCBsb25nIHJkOw0K IAlpbnQgcnE7DQogI2VuZGlmDQotCWludCBibG9nID0gc29mdG5ldF9kYXRh W2NwdV0uaW5wdXRfcGt0X3F1ZXVlLnFsZW47DQotCWludCBhdmdfYmxvZyA9 IHNvZnRuZXRfZGF0YVtjcHVdLmF2Z19ibG9nOw0KKwlpbnQgYmxvZyA9IHF1 ZXVlLT5pbnB1dF9wa3RfcXVldWUucWxlbjsNCisJaW50IGF2Z19ibG9nID0g cXVldWUtPmF2Z19ibG9nOw0KIA0KIAlhdmdfYmxvZyA9IChhdmdfYmxvZyA+ PiAxKSArIChibG9nID4+IDEpOw0KIA0KIAlpZiAoYXZnX2Jsb2cgPiBtb2Rf Y29uZykgew0KIAkJLyogQWJvdmUgbW9kZXJhdGUgY29uZ2VzdGlvbiBsZXZl bHMuICovDQotCQlzb2Z0bmV0X2RhdGFbY3B1XS5jbmdfbGV2ZWwgPSBORVRf UlhfQ05fSElHSDsNCisJCXF1ZXVlLT5jbmdfbGV2ZWwgPSBORVRfUlhfQ05f SElHSDsNCiAjaWZkZWYgUkFORF9MSUUNCiAJCXJkID0gbmV0X3JhbmRvbSgp Ow0KIAkJcnEgPSByZCAlIG5ldGRldl9tYXhfYmFja2xvZzsNCiAJCWlmIChy cSA8IGF2Z19ibG9nKSAvKiB1bmx1Y2t5IGJhc3RhcmQgKi8NCi0JCQlzb2Z0 bmV0X2RhdGFbY3B1XS5jbmdfbGV2ZWwgPSBORVRfUlhfRFJPUDsNCisJCQlx dWV1ZS0+Y25nX2xldmVsID0gTkVUX1JYX0RST1A7DQogI2VuZGlmDQogCX0g ZWxzZSBpZiAoYXZnX2Jsb2cgPiBsb19jb25nKSB7DQotCQlzb2Z0bmV0X2Rh dGFbY3B1XS5jbmdfbGV2ZWwgPSBORVRfUlhfQ05fTU9EOw0KKwkJcXVldWUt PmNuZ19sZXZlbCA9IE5FVF9SWF9DTl9NT0Q7DQogI2lmZGVmIFJBTkRfTElF DQogCQlyZCA9IG5ldF9yYW5kb20oKTsNCiAJCXJxID0gcmQgJSBuZXRkZXZf bWF4X2JhY2tsb2c7DQogCQkJaWYgKHJxIDwgYXZnX2Jsb2cpIC8qIHVubHVj a3kgYmFzdGFyZCAqLw0KLQkJCQlzb2Z0bmV0X2RhdGFbY3B1XS5jbmdfbGV2 ZWwgPSBORVRfUlhfQ05fSElHSDsNCisJCQkJcXVldWUtPmNuZ19sZXZlbCA9 IE5FVF9SWF9DTl9ISUdIOw0KICNlbmRpZg0KIAl9IGVsc2UgaWYgKGF2Z19i bG9nID4gbm9fY29uZykNCi0JCXNvZnRuZXRfZGF0YVtjcHVdLmNuZ19sZXZl bCA9IE5FVF9SWF9DTl9MT1c7DQorCQlxdWV1ZS0+Y25nX2xldmVsID0gTkVU X1JYX0NOX0xPVzsNCiAJZWxzZSAgLyogbm8gY29uZ2VzdGlvbiAqLw0KLQkJ c29mdG5ldF9kYXRhW2NwdV0uY25nX2xldmVsID0gTkVUX1JYX1NVQ0NFU1M7 DQorCQlxdWV1ZS0+Y25nX2xldmVsID0gTkVUX1JYX1NVQ0NFU1M7DQogDQot CXNvZnRuZXRfZGF0YVtjcHVdLmF2Z19ibG9nID0gYXZnX2Jsb2c7DQorCXF1 ZXVlLT5hdmdfYmxvZyA9IGF2Z19ibG9nOw0KIH0NCiANCiAjaWZkZWYgT0ZG TElORV9TQU1QTEUNCiBzdGF0aWMgdm9pZCBzYW1wbGVfcXVldWUodW5zaWdu ZWQgbG9uZyBkdW1teSkNCiB7DQotLyogMTAgbXMgMHIgMW1zIC0tIGkgZG9u dCBjYXJlIC0tIEpIUyAqLw0KLQlpbnQgbmV4dF90aWNrID0gMTsNCi0JaW50 IGNwdSA9IHNtcF9wcm9jZXNzb3JfaWQoKTsNCisJdWludCBjcHUgPSBzbXBf cHJvY2Vzc29yX2lkKCk7DQorCWludCBuZXh0X3RpY2sgPSAxOwkvKiAxMCBt cyAwciAxbXMgLS0gaSBkb250IGNhcmUgLS0gSkhTICovDQogDQogCWdldF9z YW1wbGVfc3RhdHMoY3B1KTsNCiAJbmV4dF90aWNrICs9IGppZmZpZXM7DQpA QCAtMTIwOCw2ICsxMjY1LDI4IEBADQogfQ0KICNlbmRpZg0KIA0KK3N0YXRp YyBpbmxpbmUgdm9pZCBfcXVldWVfdW50aHJvdHRsZShzdHJ1Y3Qgc29mdG5l dF9kYXRhICpxdWV1ZSkNCit7DQorCWlmIChxdWV1ZS0+dGhyb3R0bGUpIHsN CisJCXF1ZXVlLT50aHJvdHRsZSA9IDA7DQorI2lmZGVmIENPTkZJR19ORVRf SFdfRkxPV0NPTlRST0wNCisJCWlmIChhdG9taWNfZGVjX2FuZF90ZXN0KCZu ZXRkZXZfZHJvcHBpbmcpKQ0KKwkJCW5ldGRldl93YWtldXAoKTsNCisjZW5k aWYNCisJfQ0KK30NCisNCitzdGF0aWMgaW5saW5lIHZvaWQgX3F1ZXVlX3Ro cm90dGxlKHN0cnVjdCBzb2Z0bmV0X2RhdGEgKnF1ZXVlKQ0KK3sNCisJaWYg KCFxdWV1ZS0+dGhyb3R0bGUpIHsNCisJCXF1ZXVlLT50aHJvdHRsZSA9IDE7 DQorCQluZXRkZXZfcnhfc3RhdFtzbXBfcHJvY2Vzc29yX2lkKCldLnRocm90 dGxlZCsrOw0KKyNpZmRlZiBDT05GSUdfTkVUX0hXX0ZMT1dDT05UUk9MDQor CQlhdG9taWNfaW5jKCZuZXRkZXZfZHJvcHBpbmcpOw0KKyNlbmRpZg0KKwl9 DQorfQ0KKw0KIA0KIC8qKg0KICAqCW5ldGlmX3J4CS0JcG9zdCBidWZmZXIg dG8gdGhlIG5ldHdvcmsgY29kZQ0KQEAgLTEyMjksMTAxICsxMzA4LDUxIEBA DQogDQogaW50IG5ldGlmX3J4KHN0cnVjdCBza19idWZmICpza2IpDQogew0K LQlpbnQgdGhpc19jcHUgPSBzbXBfcHJvY2Vzc29yX2lkKCk7DQotCXN0cnVj dCBzb2Z0bmV0X2RhdGEgKnF1ZXVlOw0KKwl1aW50IGNwdSA9IHNtcF9wcm9j ZXNzb3JfaWQoKTsNCisJc3RydWN0IHNvZnRuZXRfZGF0YSAqcXVldWUgPSAm c29mdG5ldF9kYXRhW2NwdV07DQorCXN0cnVjdCBuZXRpZl9yeF9zdGF0cyAq c3RhdHMgPSAmbmV0ZGV2X3J4X3N0YXRbY3B1XTsNCiAJdW5zaWduZWQgbG9u ZyBmbGFnczsNCiANCiAJaWYgKCFza2ItPnN0YW1wLnR2X3NlYykNCiAJCWRv X2dldHRpbWVvZmRheSgmc2tiLT5zdGFtcCk7DQogDQotCS8qIFRoZSBjb2Rl IGlzIHJlYXJyYW5nZWQgc28gdGhhdCB0aGUgcGF0aCBpcyB0aGUgbW9zdA0K LQkgICBzaG9ydCB3aGVuIENQVSBpcyBjb25nZXN0ZWQsIGJ1dCBpcyBzdGls bCBvcGVyYXRpbmcuDQotCSAqLw0KLQlxdWV1ZSA9ICZzb2Z0bmV0X2RhdGFb dGhpc19jcHVdOw0KLQ0KIAlsb2NhbF9pcnFfc2F2ZShmbGFncyk7DQogDQot CW5ldGRldl9yeF9zdGF0W3RoaXNfY3B1XS50b3RhbCsrOw0KKwkvKg0KKwkg KiBjaGFuZ2VkIHRoZSBvcHRpbWl6ZWQgY29kZSB3aXRoIHRoZSBnb3RvIGlu c3RydWN0aW9uLA0KKwkgKiBiYWNrIHRvIHRoZSBub3JtYWxpemVkIHZlcnNp b24uIGdjYzMgd2lsbCBnZW5lcmF0ZQ0KKwkgKiB0aGUgc2FtZSBvdXRwdXQg Zm9yIGJvdGggY2FzZXMuIC10bQ0KKwkgKi8NCisJc3RhdHMtPnRvdGFsKys7 DQogCWlmIChxdWV1ZS0+aW5wdXRfcGt0X3F1ZXVlLnFsZW4gPD0gbmV0ZGV2 X21heF9iYWNrbG9nKSB7DQotCQlpZiAocXVldWUtPmlucHV0X3BrdF9xdWV1 ZS5xbGVuKSB7DQorCQlpZiAobGlrZWx5KHF1ZXVlLT5pbnB1dF9wa3RfcXVl dWUucWxlbikpIHsNCiAJCQlpZiAocXVldWUtPnRocm90dGxlKQ0KIAkJCQln b3RvIGRyb3A7DQotDQotZW5xdWV1ZToNCi0JCQlkZXZfaG9sZChza2ItPmRl dik7DQotCQkJX19za2JfcXVldWVfdGFpbCgmcXVldWUtPmlucHV0X3BrdF9x dWV1ZSwgc2tiKTsNCi0JCQlsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7DQot I2lmbmRlZiBPRkZMSU5FX1NBTVBMRQ0KLQkJCWdldF9zYW1wbGVfc3RhdHMo dGhpc19jcHUpOw0KLSNlbmRpZg0KLQkJCXJldHVybiBxdWV1ZS0+Y25nX2xl dmVsOw0KKwkJfSBlbHNlIHsNCisJCQlfcXVldWVfdW50aHJvdHRsZShxdWV1 ZSk7DQorCQkJbmV0aWZfcnhfc2NoZWR1bGUoJnF1ZXVlLT5iYWNrbG9nX2Rl dik7DQogCQl9DQogDQotCQlpZiAocXVldWUtPnRocm90dGxlKSB7DQotCQkJ cXVldWUtPnRocm90dGxlID0gMDsNCi0jaWZkZWYgQ09ORklHX05FVF9IV19G TE9XQ09OVFJPTA0KLQkJCWlmIChhdG9taWNfZGVjX2FuZF90ZXN0KCZuZXRk ZXZfZHJvcHBpbmcpKQ0KLQkJCQluZXRkZXZfd2FrZXVwKCk7DQorCQkgZGV2 X2hvbGQoc2tiLT5kZXYpOw0KKwkJX19za2JfcXVldWVfdGFpbCgmcXVldWUt PmlucHV0X3BrdF9xdWV1ZSwgc2tiKTsNCisJCWxvY2FsX2lycV9yZXN0b3Jl KGZsYWdzKTsNCisjaWZuZGVmIE9GRkxJTkVfU0FNUExFDQorCQlnZXRfc2Ft cGxlX3N0YXRzKGNwdSk7DQogI2VuZGlmDQotCQl9DQogDQotCQluZXRpZl9y eF9zY2hlZHVsZSgmcXVldWUtPmJhY2tsb2dfZGV2KTsNCi0JCWdvdG8gZW5x dWV1ZTsNCisJCXJldHVybiBxdWV1ZS0+Y25nX2xldmVsOw0KIAl9DQogDQot CWlmICghcXVldWUtPnRocm90dGxlKSB7DQotCQlxdWV1ZS0+dGhyb3R0bGUg PSAxOw0KLQkJbmV0ZGV2X3J4X3N0YXRbdGhpc19jcHVdLnRocm90dGxlZCsr Ow0KLSNpZmRlZiBDT05GSUdfTkVUX0hXX0ZMT1dDT05UUk9MDQotCQlhdG9t aWNfaW5jKCZuZXRkZXZfZHJvcHBpbmcpOw0KLSNlbmRpZg0KLQl9DQorCV9x dWV1ZV90aHJvdHRsZShxdWV1ZSk7DQogDQogZHJvcDoNCi0JbmV0ZGV2X3J4 X3N0YXRbdGhpc19jcHVdLmRyb3BwZWQrKzsNCisJc3RhdHMtPmRyb3BwZWQr KzsNCiAJbG9jYWxfaXJxX3Jlc3RvcmUoZmxhZ3MpOw0KIA0KIAlrZnJlZV9z a2Ioc2tiKTsNCiAJcmV0dXJuIE5FVF9SWF9EUk9QOw0KIH0NCiANCi0vKiBE ZWxpdmVyIHNrYiB0byBhbiBvbGQgcHJvdG9jb2wsIHdoaWNoIGlzIG5vdCB0 aHJlYWRlZCB3ZWxsDQotICAgb3Igd2hpY2ggZG8gbm90IHVuZGVyc3RhbmQg c2hhcmVkIHNrYnMuDQotICovDQotc3RhdGljIGludCBkZWxpdmVyX3RvX29s ZF9vbmVzKHN0cnVjdCBwYWNrZXRfdHlwZSAqcHQsDQotCQkJICAgICAgIHN0 cnVjdCBza19idWZmICpza2IsIGludCBsYXN0KQ0KLXsNCi0Jc3RhdGljIHNw aW5sb2NrX3QgbmV0X2JoX2xvY2sgPSBTUElOX0xPQ0tfVU5MT0NLRUQ7DQot CWludCByZXQgPSBORVRfUlhfRFJPUDsNCi0NCi0JaWYgKCFsYXN0KSB7DQot CQlza2IgPSBza2JfY2xvbmUoc2tiLCBHRlBfQVRPTUlDKTsNCi0JCWlmICgh c2tiKQ0KLQkJCWdvdG8gb3V0Ow0KLQl9DQotCWlmIChza2JfaXNfbm9ubGlu ZWFyKHNrYikgJiYgc2tiX2xpbmVhcml6ZShza2IsIEdGUF9BVE9NSUMpKQ0K LQkJZ290byBvdXRfa2ZyZWU7DQotDQotCS8qIFRoZSBhc3N1bXB0aW9uIChj b3JyZWN0IG9uZSkgaXMgdGhhdCBvbGQgcHJvdG9jb2xzDQotCSAgIGRpZCBu b3QgZGVwZW5lZCBvbiBCSHMgZGlmZmVyZW50IG9mIE5FVF9CSCBhbmQgVElN RVJfQkguDQotCSAqLw0KLQ0KLQkvKiBFbXVsYXRlIE5FVF9CSCB3aXRoIHNw ZWNpYWwgc3BpbmxvY2sgKi8NCi0Jc3Bpbl9sb2NrKCZuZXRfYmhfbG9jayk7 DQotDQotCS8qIERpc2FibGUgdGltZXJzIGFuZCB3YWl0IGZvciBhbGwgdGlt ZXJzIGNvbXBsZXRpb24gKi8NCi0JdGFza2xldF9kaXNhYmxlKGJoX3Rhc2tf dmVjK1RJTUVSX0JIKTsNCi0NCi0JcmV0ID0gcHQtPmZ1bmMoc2tiLCBza2It PmRldiwgcHQpOw0KLQ0KLQl0YXNrbGV0X2hpX2VuYWJsZShiaF90YXNrX3Zl YytUSU1FUl9CSCk7DQotCXNwaW5fdW5sb2NrKCZuZXRfYmhfbG9jayk7DQot b3V0Og0KLQlyZXR1cm4gcmV0Ow0KLW91dF9rZnJlZToNCi0Ja2ZyZWVfc2ti KHNrYik7DQotCWdvdG8gb3V0Ow0KLX0NCiANCiBzdGF0aWMgX19pbmxpbmVf XyB2b2lkIHNrYl9ib25kKHN0cnVjdCBza19idWZmICpza2IpDQogew0KQEAg LTEzMzUsMTQgKzEzNjQsMTQgQEANCiANCiBzdGF0aWMgdm9pZCBuZXRfdHhf YWN0aW9uKHN0cnVjdCBzb2Z0aXJxX2FjdGlvbiAqaCkNCiB7DQotCWludCBj cHUgPSBzbXBfcHJvY2Vzc29yX2lkKCk7DQorCXN0cnVjdCBzb2Z0bmV0X2Rh dGEgKnF1ZXVlID0gJnNvZnRuZXRfZGF0YVtzbXBfcHJvY2Vzc29yX2lkKCld Ow0KIA0KLQlpZiAoc29mdG5ldF9kYXRhW2NwdV0uY29tcGxldGlvbl9xdWV1 ZSkgew0KKwlpZiAocXVldWUtPmNvbXBsZXRpb25fcXVldWUpIHsNCiAJCXN0 cnVjdCBza19idWZmICpjbGlzdDsNCiANCiAJCWxvY2FsX2lycV9kaXNhYmxl KCk7DQotCQljbGlzdCA9IHNvZnRuZXRfZGF0YVtjcHVdLmNvbXBsZXRpb25f cXVldWU7DQotCQlzb2Z0bmV0X2RhdGFbY3B1XS5jb21wbGV0aW9uX3F1ZXVl ID0gTlVMTDsNCisJCWNsaXN0ID0gcXVldWUtPmNvbXBsZXRpb25fcXVldWU7 DQorCQlxdWV1ZS0+Y29tcGxldGlvbl9xdWV1ZSA9IE5VTEw7DQogCQlsb2Nh bF9pcnFfZW5hYmxlKCk7DQogDQogCQl3aGlsZSAoY2xpc3QpIHsNCkBAIC0x MzU0LDEyICsxMzgzLDEyIEBADQogCQl9DQogCX0NCiANCi0JaWYgKHNvZnRu ZXRfZGF0YVtjcHVdLm91dHB1dF9xdWV1ZSkgew0KKwlpZiAocXVldWUtPm91 dHB1dF9xdWV1ZSkgew0KIAkJc3RydWN0IG5ldF9kZXZpY2UgKmhlYWQ7DQog DQogCQlsb2NhbF9pcnFfZGlzYWJsZSgpOw0KLQkJaGVhZCA9IHNvZnRuZXRf ZGF0YVtjcHVdLm91dHB1dF9xdWV1ZTsNCi0JCXNvZnRuZXRfZGF0YVtjcHVd Lm91dHB1dF9xdWV1ZSA9IE5VTEw7DQorCQloZWFkID0gcXVldWUtPm91dHB1 dF9xdWV1ZTsNCisJCXF1ZXVlLT5vdXRwdXRfcXVldWUgPSBOVUxMOw0KIAkJ bG9jYWxfaXJxX2VuYWJsZSgpOw0KIA0KIAkJd2hpbGUgKGhlYWQpIHsNCkBA IC0xMzk3LDQwICsxNDI2LDEyIEBADQogdm9pZCAoKmJyX2hhbmRsZV9mcmFt ZV9ob29rKShzdHJ1Y3Qgc2tfYnVmZiAqc2tiKSA9IE5VTEw7DQogI2VuZGlm DQogDQotc3RhdGljIF9faW5saW5lX18gaW50IGhhbmRsZV9icmlkZ2Uoc3Ry dWN0IHNrX2J1ZmYgKnNrYiwNCi0JCQkJICAgICBzdHJ1Y3QgcGFja2V0X3R5 cGUgKnB0X3ByZXYpDQotew0KLQlpbnQgcmV0ID0gTkVUX1JYX0RST1A7DQot DQotCWlmIChwdF9wcmV2KSB7DQotCQlpZiAoIXB0X3ByZXYtPmRhdGEpDQot CQkJcmV0ID0gZGVsaXZlcl90b19vbGRfb25lcyhwdF9wcmV2LCBza2IsIDAp Ow0KLQkJZWxzZSB7DQotCQkJYXRvbWljX2luYygmc2tiLT51c2Vycyk7DQot CQkJcmV0ID0gcHRfcHJldi0+ZnVuYyhza2IsIHNrYi0+ZGV2LCBwdF9wcmV2 KTsNCi0JCX0NCi0JfQ0KLQ0KLQlicl9oYW5kbGVfZnJhbWVfaG9vayhza2Ip Ow0KLQlyZXR1cm4gcmV0Ow0KLX0NCi0NCi0NCi0jaWZkZWYgQ09ORklHX05F VF9ESVZFUlQNCi1zdGF0aWMgaW5saW5lIGludCBoYW5kbGVfZGl2ZXJ0ZXIo c3RydWN0IHNrX2J1ZmYgKnNrYikNCi17DQotCS8qIGlmIGRpdmVyc2lvbiBp cyBzdXBwb3J0ZWQgb24gZGV2aWNlLCB0aGVuIGRpdmVydCAqLw0KLQlpZiAo c2tiLT5kZXYtPmRpdmVydCAmJiBza2ItPmRldi0+ZGl2ZXJ0LT5kaXZlcnQp DQotCQlkaXZlcnRfZnJhbWUoc2tiKTsNCi0JcmV0dXJuIDA7DQotfQ0KLSNl bmRpZiAgIC8qIENPTkZJR19ORVRfRElWRVJUICovDQotDQogaW50IG5ldGlm X3JlY2VpdmVfc2tiKHN0cnVjdCBza19idWZmICpza2IpDQogew0KIAlzdHJ1 Y3QgcGFja2V0X3R5cGUgKnB0eXBlLCAqcHRfcHJldjsNCiAJaW50IHJldCA9 IE5FVF9SWF9EUk9QOw0KIAl1bnNpZ25lZCBzaG9ydCB0eXBlID0gc2tiLT5w cm90b2NvbDsNCisJc3RydWN0IG5ldF9kZXZpY2UgKmRldiA9IHNrYi0+ZGV2 Ow0KIA0KIAlpZiAoIXNrYi0+c3RhbXAudHZfc2VjKQ0KIAkJZG9fZ2V0dGlt ZW9mZGF5KCZza2ItPnN0YW1wKTsNCkBAIC0xNDQ5LDU5ICsxNDUwLDUyIEBA DQogCXNrYi0+aC5yYXcgPSBza2ItPm5oLnJhdyA9IHNrYi0+ZGF0YTsNCiAN CiAJcHRfcHJldiA9IE5VTEw7DQorCS8qIGRlbGl2ZXIgc2tiIHRvIFRBUHMg Ki8NCisNCiAJZm9yIChwdHlwZSA9IHB0eXBlX2FsbDsgcHR5cGU7IHB0eXBl ID0gcHR5cGUtPm5leHQpIHsNCi0JCWlmICghcHR5cGUtPmRldiB8fCBwdHlw ZS0+ZGV2ID09IHNrYi0+ZGV2KSB7DQotCQkJaWYgKHB0X3ByZXYpIHsNCi0J CQkJaWYgKCFwdF9wcmV2LT5kYXRhKSB7DQotCQkJCQlyZXQgPSBkZWxpdmVy X3RvX29sZF9vbmVzKHB0X3ByZXYsDQotCQkJCQkJCQkgIHNrYiwgMCk7DQot CQkJCX0gZWxzZSB7DQotCQkJCQlhdG9taWNfaW5jKCZza2ItPnVzZXJzKTsN Ci0JCQkJCXJldCA9IHB0X3ByZXYtPmZ1bmMoc2tiLCBza2ItPmRldiwNCi0J CQkJCQkJICAgIHB0X3ByZXYpOw0KLQkJCQl9DQotCQkJfQ0KKwkJaWYgKCFw dHlwZS0+ZGV2IHx8IHB0eXBlLT5kZXYgPT0gZGV2KSB7DQorCQkJaWYgKHB0 X3ByZXYpDQorCQkJCXJldCA9IF9kZWxpdmVyX3RvX3Byb3RvIChza2IsIHB0 X3ByZXYsIDApOw0KIAkJCXB0X3ByZXYgPSBwdHlwZTsNCiAJCX0NCiAJfQ0K IA0KICNpZmRlZiBDT05GSUdfTkVUX0RJVkVSVA0KLQlpZiAoc2tiLT5kZXYt PmRpdmVydCAmJiBza2ItPmRldi0+ZGl2ZXJ0LT5kaXZlcnQpDQotCQlyZXQg PSBoYW5kbGVfZGl2ZXJ0ZXIoc2tiKTsNCi0jZW5kaWYgLyogQ09ORklHX05F VF9ESVZFUlQgKi8NCisJLyogZG8gcG9zc2libGUgaW5qZWN0aW9uL3JlamVj dGlvbiBvZiBwYWNrZXRzICovDQorCWlmIChkZXYtPmRpdmVydCAmJiBkZXYt PmRpdmVydC0+ZGl2ZXJ0KSB7DQorCQlkaXZlcnRfZnJhbWUoc2tiKTsNCisJ fQ0KKyNlbmRpZg0KIA0KICNpZiBkZWZpbmVkKENPTkZJR19CUklER0UpIHx8 IGRlZmluZWQoQ09ORklHX0JSSURHRV9NT0RVTEUpDQotCWlmIChza2ItPmRl di0+YnJfcG9ydCAmJiBicl9oYW5kbGVfZnJhbWVfaG9vaykgew0KLQkJcmV0 dXJuIGhhbmRsZV9icmlkZ2Uoc2tiLCBwdF9wcmV2KTsNCisJLyogYnJpZGdl IHRoZSBwYWNrZXQgdG8gdGhlIGJyaWRnZSBpbnRlcmZhY2UgKi8NCisJaWYg KGRldi0+YnJfcG9ydCAmJiBicl9oYW5kbGVfZnJhbWVfaG9vaykgew0KKwkJ aWYgKHB0X3ByZXYpDQorCQkJcmV0ID0gX2RlbGl2ZXJfdG9fcHJvdG8oc2ti LCBwdF9wcmV2LCAxKTsNCisNCisJCWJyX2hhbmRsZV9mcmFtZV9ob29rKHNr Yik7DQorDQorCQlyZXR1cm4gcmV0Ow0KIAl9DQogI2VuZGlmDQogDQorCS8q IGRlbGl2ZXIgc2tiIHRvIHJlZ2lzdGVyZWQgcHJvdG9jb2xzIChlLmcuIElQ KSAqLw0KIAlmb3IgKHB0eXBlID0gcHR5cGVfYmFzZVtudG9ocyh0eXBlKSAm IDE1XTsgcHR5cGU7IHB0eXBlID0gcHR5cGUtPm5leHQpIHsNCi0JCWlmIChw dHlwZS0+dHlwZSA9PSB0eXBlICYmDQotCQkgICAgKCFwdHlwZS0+ZGV2IHx8 IHB0eXBlLT5kZXYgPT0gc2tiLT5kZXYpKSB7DQotCQkJaWYgKHB0X3ByZXYp IHsNCi0JCQkJaWYgKCFwdF9wcmV2LT5kYXRhKSB7DQotCQkJCQlyZXQgPSBk ZWxpdmVyX3RvX29sZF9vbmVzKHB0X3ByZXYsDQotCQkJCQkJCQkgIHNrYiwg MCk7DQotCQkJCX0gZWxzZSB7DQotCQkJCQlhdG9taWNfaW5jKCZza2ItPnVz ZXJzKTsNCi0JCQkJCXJldCA9IHB0X3ByZXYtPmZ1bmMoc2tiLCBza2ItPmRl diwNCi0JCQkJCQkJICAgIHB0X3ByZXYpOw0KLQkJCQl9DQotCQkJfQ0KKwkJ aWYgKHB0eXBlLT50eXBlICE9IHR5cGUpDQorCQkgICAgICAgY29udGludWU7 DQorCQlpZiAoIXB0eXBlLT5kZXYgfHwgcHR5cGUtPmRldiA9PSBkZXYpIHsN CisJCQlpZiAocHRfcHJldikNCisJCQkJcmV0ID0gX2RlbGl2ZXJfdG9fcHJv dG8oc2tiLCBwdF9wcmV2LCAwKTsNCiAJCQlwdF9wcmV2ID0gcHR5cGU7DQog CQl9DQogCX0NCiANCiAJaWYgKHB0X3ByZXYpIHsNCi0JCWlmICghcHRfcHJl di0+ZGF0YSkgew0KLQkJCXJldCA9IGRlbGl2ZXJfdG9fb2xkX29uZXMocHRf cHJldiwgc2tiLCAxKTsNCi0JCX0gZWxzZSB7DQotCQkJcmV0ID0gcHRfcHJl di0+ZnVuYyhza2IsIHNrYi0+ZGV2LCBwdF9wcmV2KTsNCi0JCX0NCisJCXJl dCA9IF9kZWxpdmVyX3RvX3Byb3RvKHNrYiwgcHRfcHJldiwgMSk7DQogCX0g ZWxzZSB7DQogCQlrZnJlZV9za2Ioc2tiKTsNCi0JCS8qIEphbWFsLCBub3cg eW91IHdpbGwgbm90IGFibGUgdG8gZXNjYXBlIGV4cGxhaW5pbmcNCisJCS8q DQorCQkgKiBKYW1hbCwgbm93IHlvdSB3aWxsIG5vdCBhYmxlIHRvIGVzY2Fw ZSBleHBsYWluaW5nDQogCQkgKiBtZSBob3cgeW91IHdlcmUgZ29pbmcgdG8g dXNlIHRoaXMuIDotKQ0KIAkJICovDQogCQlyZXQgPSBORVRfUlhfRFJPUDsN CkBAIC0xNTEyLDExICsxNTA2LDEwIEBADQogDQogc3RhdGljIGludCBwcm9j ZXNzX2JhY2tsb2coc3RydWN0IG5ldF9kZXZpY2UgKmJhY2tsb2dfZGV2LCBp bnQgKmJ1ZGdldCkNCiB7DQotCWludCB3b3JrID0gMDsNCisJc3RydWN0IHNv ZnRuZXRfZGF0YSAqcXVldWUgPSAmc29mdG5ldF9kYXRhW3NtcF9wcm9jZXNz b3JfaWQoKV07DQogCWludCBxdW90YSA9IG1pbihiYWNrbG9nX2Rldi0+cXVv dGEsICpidWRnZXQpOw0KLQlpbnQgdGhpc19jcHUgPSBzbXBfcHJvY2Vzc29y X2lkKCk7DQotCXN0cnVjdCBzb2Z0bmV0X2RhdGEgKnF1ZXVlID0gJnNvZnRu ZXRfZGF0YVt0aGlzX2NwdV07DQogCXVuc2lnbmVkIGxvbmcgc3RhcnRfdGlt ZSA9IGppZmZpZXM7DQorCWludCB3b3JrID0gMDsNCiANCiAJZm9yICg7Oykg ew0KIAkJc3RydWN0IHNrX2J1ZmYgKnNrYjsNCkBAIC0xNTc1LDggKzE1Njgs OSBAQA0KIA0KIHN0YXRpYyB2b2lkIG5ldF9yeF9hY3Rpb24oc3RydWN0IHNv ZnRpcnFfYWN0aW9uICpoKQ0KIHsNCi0JaW50IHRoaXNfY3B1ID0gc21wX3By b2Nlc3Nvcl9pZCgpOw0KLQlzdHJ1Y3Qgc29mdG5ldF9kYXRhICpxdWV1ZSA9 ICZzb2Z0bmV0X2RhdGFbdGhpc19jcHVdOw0KKwl1aW50IGNwdSA9IHNtcF9w cm9jZXNzb3JfaWQoKTsNCisJc3RydWN0IHNvZnRuZXRfZGF0YSAqcXVldWUg PSAmc29mdG5ldF9kYXRhW2NwdV07DQorCXN0cnVjdCBuZXRpZl9yeF9zdGF0 cyAqc3RhdHMgPSAmbmV0ZGV2X3J4X3N0YXRbY3B1XTsNCiAJdW5zaWduZWQg bG9uZyBzdGFydF90aW1lID0gamlmZmllczsNCiAJaW50IGJ1ZGdldCA9IG5l dGRldl9tYXhfYmFja2xvZzsNCiANCkBAIC0xNjEzLDggKzE2MDcsOCBAQA0K IAlyZXR1cm47DQogDQogc29mdG5ldF9icmVhazoNCi0JbmV0ZGV2X3J4X3N0 YXRbdGhpc19jcHVdLnRpbWVfc3F1ZWV6ZSsrOw0KLQlfX2NwdV9yYWlzZV9z b2Z0aXJxKHRoaXNfY3B1LCBORVRfUlhfU09GVElSUSk7DQorCXN0YXRzLT50 aW1lX3NxdWVlemUrKzsNCisJX19jcHVfcmFpc2Vfc29mdGlycShjcHUsIE5F VF9SWF9TT0ZUSVJRKTsNCiAJZ290byBvdXQ7DQogfQ0KIA0KQEAgLTE4MTcs MjUgKzE4MTEsMjcgQEANCiBzdGF0aWMgaW50IGRldl9wcm9jX3N0YXRzKGNo YXIgKmJ1ZmZlciwgY2hhciAqKnN0YXJ0LCBvZmZfdCBvZmZzZXQsDQogCQkJ ICBpbnQgbGVuZ3RoLCBpbnQgKmVvZiwgdm9pZCAqZGF0YSkNCiB7DQotCWlu dCBpLCBsY3B1Ow0KKwlzdHJ1Y3QgbmV0aWZfcnhfc3RhdHMgKnN0YXRzOw0K KyAgICAgICAJdWludCBjcHU7DQogCWludCBsZW4gPSAwOw0KIA0KLQlmb3Ig KGxjcHUgPSAwOyBsY3B1IDwgc21wX251bV9jcHVzOyBsY3B1KyspIHsNCi0J CWkgPSBjcHVfbG9naWNhbF9tYXAobGNwdSk7DQorCWZvciAoY3B1ID0gMDsg Y3B1IDwgc21wX251bV9jcHVzOyBjcHUrKykgew0KKwkJc3RhdHMgPSAmbmV0 ZGV2X3J4X3N0YXRbY3B1X2xvZ2ljYWxfbWFwKGNwdSldOw0KKw0KIAkJbGVu ICs9IHNwcmludGYoYnVmZmVyICsgbGVuLCAiJTA4eCAlMDh4ICUwOHggJTA4 eCAlMDh4ICUwOHggIg0KIAkJCQkJICAgICAiJTA4eCAlMDh4ICUwOHhcbiIs DQotCQkJICAgICAgIG5ldGRldl9yeF9zdGF0W2ldLnRvdGFsLA0KLQkJCSAg ICAgICBuZXRkZXZfcnhfc3RhdFtpXS5kcm9wcGVkLA0KLQkJCSAgICAgICBu ZXRkZXZfcnhfc3RhdFtpXS50aW1lX3NxdWVlemUsDQotCQkJICAgICAgIG5l dGRldl9yeF9zdGF0W2ldLnRocm90dGxlZCwNCi0JCQkgICAgICAgbmV0ZGV2 X3J4X3N0YXRbaV0uZmFzdHJvdXRlX2hpdCwNCi0JCQkgICAgICAgbmV0ZGV2 X3J4X3N0YXRbaV0uZmFzdHJvdXRlX3N1Y2Nlc3MsDQotCQkJICAgICAgIG5l dGRldl9yeF9zdGF0W2ldLmZhc3Ryb3V0ZV9kZWZlciwNCi0JCQkgICAgICAg bmV0ZGV2X3J4X3N0YXRbaV0uZmFzdHJvdXRlX2RlZmVycmVkX291dCwNCisJ CQkgICAgICAgc3RhdHMtPnRvdGFsLA0KKwkJCSAgICAgICBzdGF0cy0+ZHJv cHBlZCwNCisJCQkgICAgICAgc3RhdHMtPnRpbWVfc3F1ZWV6ZSwNCisJCQkg ICAgICAgc3RhdHMtPnRocm90dGxlZCwNCisJCQkgICAgICAgc3RhdHMtPmZh c3Ryb3V0ZV9oaXQsDQorCQkJICAgICAgIHN0YXRzLT5mYXN0cm91dGVfc3Vj Y2VzcywNCisJCQkgICAgICAgc3RhdHMtPmZhc3Ryb3V0ZV9kZWZlciwNCisJ CQkgICAgICAgc3RhdHMtPmZhc3Ryb3V0ZV9kZWZlcnJlZF9vdXQsDQogI2lm IDANCi0JCQkgICAgICAgbmV0ZGV2X3J4X3N0YXRbaV0uZmFzdHJvdXRlX2xh dGVuY3lfcmVkdWN0aW9uDQorCQkJICAgICAgIHN0YXRzLT5mYXN0cm91dGVf bGF0ZW5jeV9yZWR1Y3Rpb24NCiAjZWxzZQ0KLQkJCSAgICAgICBuZXRkZXZf cnhfc3RhdFtpXS5jcHVfY29sbGlzaW9uDQorCQkJICAgICAgIHN0YXRzLT5j cHVfY29sbGlzaW9uDQogI2VuZGlmDQogCQkJICAgICAgICk7DQogCX0NCkBA IC0yNTIyLDcgKzI1MTgsNyBAQA0KIAkJcmV0dXJuIDA7DQogCX0NCiAjaWZk ZWYgTkVUX1JFRkNOVF9ERUJVRw0KLQlwcmludGsoS0VSTl9ERUJVRyAibmV0 ZGV2X2ZpbmlzaF91bnJlZ2lzdGVyOiAlcyVzLlxuIiwgZGV2LT5uYW1lLA0K KwlwcmludGsoS0VSTl9ERUJVRyAiJXM6ICVzJXMuXG4iLCBfX2Z1bmNfXywg ZGV2LT5uYW1lLA0KIAkgICAgICAgKGRldi0+ZmVhdHVyZXMgJiBORVRJRl9G X0RZTkFMTE9DKT8iIjoiLCBvbGQgc3R5bGUiKTsNCiAjZW5kaWYNCiAJaWYg KGRldi0+ZGVzdHJ1Y3RvcikNCkBAIC0yNTY3LDggKzI1NjMsOCBAQA0KIAkJ fQ0KIAl9DQogCWlmICghZCkgew0KLQkJcHJpbnRrKEtFUk5fREVCVUcgInVu cmVnaXN0ZXJfbmV0ZGV2aWNlOiBkZXZpY2UgJXMvJXAgbmV2ZXIgIg0KLQkJ CQkgICJ3YXMgcmVnaXN0ZXJlZFxuIiwgZGV2LT5uYW1lLCBkZXYpOw0KKwkJ cHJpbnRrKEtFUk5fREVCVUcgIiVzOiBkZXZpY2UgJXMvJXAgd2FzIG5ldmVy IHJlZ2lzdGVyZWRcbiIsDQorCQkJCSAgX19mdW5jX18sIGRldi0+bmFtZSwg ZGV2KTsNCiAJCXJldHVybiAtRU5PREVWOw0KIAl9DQogDQpAQCAtMjYxMCw5 ICsyNjA2LDkgQEANCiAJaWYgKGRldi0+ZmVhdHVyZXMgJiBORVRJRl9GX0RZ TkFMTE9DKSB7DQogI2lmZGVmIE5FVF9SRUZDTlRfREVCVUcNCiAJCWlmIChh dG9taWNfcmVhZCgmZGV2LT5yZWZjbnQpICE9IDEpDQotCQkJcHJpbnRrKEtF Uk5fREVCVUcgInVucmVnaXN0ZXJfbmV0ZGV2aWNlOiBob2xkaW5nICVzICIN Ci0JCQkJCSAgInJlZmNudD0lZFxuIiwNCi0JCQkgICAgICAgZGV2LT5uYW1l LCBhdG9taWNfcmVhZCgmZGV2LT5yZWZjbnQpIC0gMSk7DQorCQkJcHJpbnRr KEtFUk5fREVCVUcgIiVzOiBob2xkaW5nICVzIHJlZmNudD0lZFxuIiwNCisJ CQkgICAgICAgX19mdW5jX18sIGRldi0+bmFtZSwNCisJCQkgICAgICAgYXRv bWljX3JlYWQoJmRldi0+cmVmY250KSAtIDEpOw0KICNlbmRpZg0KIAkJZ290 byBvdXQ7DQogCX0NCkBAIC0yNjIyLDggKzI2MTgsOCBAQA0KIAkJZ290byBv dXQ7DQogDQogI2lmZGVmIE5FVF9SRUZDTlRfREVCVUcNCi0JcHJpbnRrKEtF Uk5fREVCVUcgInVucmVnaXN0ZXJfbmV0ZGV2aWNlOiB3YWl0aW5nICVzIHJl ZmNudD0lZFxuIiwNCi0JICAgICAgIGRldi0+bmFtZSwgYXRvbWljX3JlYWQo JmRldi0+cmVmY250KSk7DQorCXByaW50ayhLRVJOX0RFQlVHICIlczogd2Fp dGluZyAlcyByZWZjbnQ9JWRcbiIsDQorCSAgICAgICBfX2Z1bmNfXywgZGV2 LT5uYW1lLCBhdG9taWNfcmVhZCgmZGV2LT5yZWZjbnQpKTsNCiAjZW5kaWYN CiANCiAJLyogRVhQTEFOQVRJT04uIElmIGRldi0+cmVmY250IGlzIG5vdCBu b3cgMSAob3VyIG93biByZWZlcmVuY2UpDQpAQCAtMjY2MSw4ICsyNjU3LDgg QEANCiAJCXNjaGVkdWxlX3RpbWVvdXQoSFogLyA0KTsNCiAJCWN1cnJlbnQt PnN0YXRlID0gVEFTS19SVU5OSU5HOw0KIAkJaWYgKChqaWZmaWVzIC0gd2Fy bmluZ190aW1lKSA+IDEwICogSFopIHsNCi0JCQlwcmludGsoS0VSTl9FTUVS RyAidW5yZWdpc3Rlcl9uZXRkZXZpY2U6IHdhaXRpbmcgZm9yICINCi0JCQkg ICAgICAgIiVzIHRvIGJlY29tZSBmcmVlLiBVc2FnZSBjb3VudCA9ICVkXG4i LA0KKwkJCXByaW50ayhLRVJOX0VNRVJHICJ3YWl0aW5nIGZvciAlcyB0byBi ZWNvbWUgZnJlZS4gIg0KKwkJCSAgICAgICAiVXNhZ2UgY291bnQgPSAlZFxu IiwNCiAJCQkgICAgICAgZGV2LT5uYW1lLCBhdG9taWNfcmVhZCgmZGV2LT5y ZWZjbnQpKTsNCiAJCQl3YXJuaW5nX3RpbWUgPSBqaWZmaWVzOw0KIAkJfQ0K QEAgLTI4NDIsMjQgKzI4MzgsMjEgQEANCiBzdGF0aWMgaW50IG5ldF9ydW5f c2Jpbl9ob3RwbHVnKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIGNoYXIgKmFj dGlvbikNCiB7DQogCWNoYXIgKmFyZ3ZbM10sICplbnZwWzVdLCBpZm5hbWVb MTIgKyBJRk5BTVNJWl0sIGFjdGlvbl9zdHJbMzJdOw0KLQlpbnQgaTsNCiAN CiAJc3ByaW50ZihpZm5hbWUsICJJTlRFUkZBQ0U9JXMiLCBkZXYtPm5hbWUp Ow0KIAlzcHJpbnRmKGFjdGlvbl9zdHIsICJBQ1RJT049JXMiLCBhY3Rpb24p Ow0KIA0KLSAgICAgICAgaSA9IDA7DQotICAgICAgICBhcmd2W2krK10gPSBo b3RwbHVnX3BhdGg7DQotICAgICAgICBhcmd2W2krK10gPSAibmV0IjsNCi0g ICAgICAgIGFyZ3ZbaV0gPSAwOw0KKyAgICAgICAgYXJndlswXSA9IGhvdHBs dWdfcGF0aDsNCisgICAgICAgIGFyZ3ZbMV0gPSAibmV0IjsNCisgICAgICAg IGFyZ3ZbMl0gPSBOVUxMOw0KIA0KLQlpID0gMDsNCiAJLyogbWluaW1hbCBj b21tYW5kIGVudmlyb25tZW50ICovDQotCWVudnAgW2krK10gPSAiSE9NRT0v IjsNCi0JZW52cCBbaSsrXSA9ICJQQVRIPS9zYmluOi9iaW46L3Vzci9zYmlu Oi91c3IvYmluIjsNCi0JZW52cCBbaSsrXSA9IGlmbmFtZTsNCi0JZW52cCBb aSsrXSA9IGFjdGlvbl9zdHI7DQotCWVudnAgW2ldID0gMDsNCisJZW52cCBb MF0gPSAiSE9NRT0vIjsNCisJZW52cCBbMV0gPSAiUEFUSD0vc2JpbjovYmlu Oi91c3Ivc2JpbjovdXNyL2JpbiI7DQorCWVudnAgWzJdID0gaWZuYW1lOw0K KwllbnZwIFszXSA9IGFjdGlvbl9zdHI7DQorCWVudnAgWzRdID0gTlVMTDsN CiANCi0JcmV0dXJuIGNhbGxfdXNlcm1vZGVoZWxwZXIoYXJndiBbMF0sIGFy Z3YsIGVudnApOw0KKwlyZXR1cm4gY2FsbF91c2VybW9kZWhlbHBlcihhcmd2 WzBdLCBhcmd2LCBlbnZwKTsNCiB9DQogI2VuZGlmDQo= ---559023410-457399677-1023639378=:16392-- From owner-netdev@oss.sgi.com Sun Jun 9 10:30:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g59HUgnC018238 for ; Sun, 9 Jun 2002 10:30:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g59HUgAq018237 for netdev-outgoing; Sun, 9 Jun 2002 10:30:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g59HUZnC018233 for ; Sun, 9 Jun 2002 10:30:35 -0700 Received: from data.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA19251; Sun, 9 Jun 2002 10:29:37 -0700 Received: from mvista.com (IDENT:george@localhost [127.0.0.1]) by data.mvista.com (8.9.3/8.9.3) with ESMTP id KAA28854; Sun, 9 Jun 2002 10:31:14 -0700 Message-ID: <3D0390E2.1B80ADEE@mvista.com> Date: Sun, 09 Jun 2002 10:31:14 -0700 From: george anzinger Organization: Monta Vista Software X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12-20b i686) X-Accept-Language: en MIME-Version: 1.0 To: kuznet@ms2.inr.ac.ru CC: netdev@oss.sgi.com, linux-net@vger.kernel.org, davem@redhat.com, ak@muc.de, pekkas@netcore.fi Subject: Network oops References: <200205202125.BAA03545@sex.inr.ac.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Is this sort of thing expected when the NIC is out of poop? <4>eth1: card reports no resources. <4>KERNEL: assertion ((int)tcp_packets_in_flight(tp) >= 0) failed at tcp_input.c(956):tcp_sacktag_write_queue <7>Leak l=8 4 <1>Unable to handle kernel NULL pointer dereference at virtual address 00000049 <4> printing eip: <4>c025b7aa <1>*pde = 00000000 <4>Oops: 0000 <4>CPU: 0 <4>EIP: 0010:[] Not tainted <4>EFLAGS: 00010207 <4>eax: c40d82c8 ebx: 00000000 ecx: 00000004 edx: 00000000 <4>esi: c40d8338 edi: c40d8260 ebp: c0437eb4 esp: c0437ea4 <4>ds: 0018 es: 0018 ss: 0018 <4>Process swapper (pid: 0, stackpage=c0437000) <4>Stack: 0000002e c40d8260 c40d8338 c40d8260 c0437ee4 c0264e8b c40d8260 00000000 <4> 00000001 c73cd944 00000009 c0437f10 c887250f c40d8260 c40d8338 c0436000 <4> c0437f08 c02650a6 c40d8260 c037edb8 00000094 00000000 c0437f08 c40d8260 <4>Call Trace: [] [] [] [] [] <4> [] [] [] [] [] [] <4> [] <4> <4>Code: 0f b6 4b 49 f6 c1 82 74 0c 31 d2 89 96 78 01 00 00 0f b6 4b STACK TRACE FOR TASK: 0xc0436000 (swapper) 0 tcp_enter_loss+202 [0xc025b7aa] 1 tcp_retransmit_timer+566 [0xc0264e86] 2 tcp_write_timer+225 [0xc02650a1] 3 timer_bh+710 [0xc01296a6] 4 timer_softirq+39 [0xc01297a7] 5 do_softirq+249 [0xc0124eb9] 6 do_IRQ+525 [0xc0109add] 7 do_IRQ+525 [0xc0109add] -- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Real time sched: http://sourceforge.net/projects/rtsched/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml From owner-netdev@oss.sgi.com Sun Jun 9 11:21:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g59ILVnC018710 for ; Sun, 9 Jun 2002 11:21:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g59ILVk7018709 for netdev-outgoing; Sun, 9 Jun 2002 11:21:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from grok.yi.org (IDENT:831F7/QBU1G7rmFAszT69Zdl1tdy0tkl@ip68-3-14-32.ph.ph.cox.net [68.3.14.32]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g59ILQnC018706 for ; Sun, 9 Jun 2002 11:21:27 -0700 Received: from candelatech.com (IDENT:jp9Q56hmljqrXMvvN8nwQlagPEx5eZxx@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g59INUL13768; Sun, 9 Jun 2002 11:23:30 -0700 Message-ID: <3D039D22.2010805@candelatech.com> Date: Sun, 09 Jun 2002 11:23:30 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: "David S. Miller" CC: mark@mark.mielke.cc, cfriesen@nortelnetworks.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: RFC: per-socket statistics on received/dropped packets References: <20020608170511.B26821@mark.mielke.cc> <20020608.160407.101346167.davem@redhat.com> <3D029DAF.5040006@candelatech.com> <20020608.175108.84748597.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk David S. Miller wrote: > From: Ben Greear > Date: Sat, 08 Jun 2002 17:13:35 -0700 > > If you're talking per-socket SNMP counters, then that could work. > General protocol-wide counters would not help much, at least > in my case. > > Why not? If you know where the drops are occurring, what else > do you need to know? I need to account for packets on a per-session basis, where a session endpoint is a UDP port. So, knowing global protocol numbers is good, but it is not very useful for the detailed accounting I need. I could also use per-socket TCP counters, like re-transmits, etc. I have not looked to see if they are already there or not... Thanks, Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From owner-netdev@oss.sgi.com Sun Jun 9 21:34:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5A4Y3nC023276 for ; Sun, 9 Jun 2002 21:34:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5A4Y39Q023275 for netdev-outgoing; Sun, 9 Jun 2002 21:34:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5A4Y1nC023269 for ; Sun, 9 Jun 2002 21:34:01 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id VAA06407; Sun, 9 Jun 2002 21:31:50 -0700 Date: Sun, 09 Jun 2002 21:31:50 -0700 (PDT) Message-Id: <20020609.213150.32126725.davem@redhat.com> To: george@mvista.com Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-net@vger.kernel.org, ak@muc.de, pekkas@netcore.fi Subject: Re: Network oops From: "David S. Miller" In-Reply-To: <3D0390E2.1B80ADEE@mvista.com> References: <200205202125.BAA03545@sex.inr.ac.ru> <3D0390E2.1B80ADEE@mvista.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk No mention of what kernel version, what patches applied, etc. so we cannot help you. From owner-netdev@oss.sgi.com Sun Jun 9 21:34:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5A4YZnC023290 for ; Sun, 9 Jun 2002 21:34:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5A4YZ64023289 for netdev-outgoing; Sun, 9 Jun 2002 21:34:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5A4YXnC023285 for ; Sun, 9 Jun 2002 21:34:33 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id VAA06414; Sun, 9 Jun 2002 21:32:24 -0700 Date: Sun, 09 Jun 2002 21:32:24 -0700 (PDT) Message-Id: <20020609.213224.01016187.davem@redhat.com> To: george@mvista.com Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-net@vger.kernel.org, ak@muc.de, pekkas@netcore.fi Subject: Re: Network oops From: "David S. Miller" In-Reply-To: <3D0390E2.1B80ADEE@mvista.com> References: <200205202125.BAA03545@sex.inr.ac.ru> <3D0390E2.1B80ADEE@mvista.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Also we need to know what network driver, if preemption is being used (being from mvista I assume you are using preemption, and if so make sure you have the preemption networking patches applied). From owner-netdev@oss.sgi.com Sun Jun 9 21:36:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5A4aYnC023353 for ; Sun, 9 Jun 2002 21:36:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5A4aYq0023352 for netdev-outgoing; Sun, 9 Jun 2002 21:36:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5A4aWnC023349 for ; Sun, 9 Jun 2002 21:36:32 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id VAA06456; Sun, 9 Jun 2002 21:34:40 -0700 Date: Sun, 09 Jun 2002 21:34:40 -0700 (PDT) Message-Id: <20020609.213440.04716391.davem@redhat.com> To: greearb@candelatech.com Cc: mark@mark.mielke.cc, cfriesen@nortelnetworks.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: RFC: per-socket statistics on received/dropped packets From: "David S. Miller" In-Reply-To: <3D039D22.2010805@candelatech.com> References: <3D029DAF.5040006@candelatech.com> <20020608.175108.84748597.davem@redhat.com> <3D039D22.2010805@candelatech.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk From: Ben Greear Date: Sun, 09 Jun 2002 11:23:30 -0700 I need to account for packets on a per-session basis, where a session endpoint is a UDP port. So, knowing global protocol numbers is good, but it is not very useful for the detailed accounting I need. Why can't you just disable the other UDP services, and then there is no question which UDP server/client is causing the drops. Every argument I hear is one out of lazyness. And that is not a reason to add something. Simply put, I don't want to add all of this per-socket counter bumping that only, at best, 1 tenth of 1 percent of people will use. This means that the rest of the world eats the overhead just for this small group that actually uses it. From owner-netdev@oss.sgi.com Sun Jun 9 21:48:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5A4m7nC023670 for ; Sun, 9 Jun 2002 21:48:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5A4m7mb023669 for netdev-outgoing; Sun, 9 Jun 2002 21:48:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5A4m4nC023666 for ; Sun, 9 Jun 2002 21:48:04 -0700 Received: from data.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id VAA24016; Sun, 9 Jun 2002 21:47:01 -0700 Received: from mvista.com (IDENT:george@localhost [127.0.0.1]) by data.mvista.com (8.9.3/8.9.3) with ESMTP id VAA15362; Sun, 9 Jun 2002 21:48:15 -0700 Message-ID: <3D042F8F.72764243@mvista.com> Date: Sun, 09 Jun 2002 21:48:15 -0700 From: george anzinger Organization: Monta Vista Software X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12-20b i686) X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-net@vger.kernel.org, ak@muc.de, pekkas@netcore.fi Subject: Re: Network oops References: <200205202125.BAA03545@sex.inr.ac.ru> <3D0390E2.1B80ADEE@mvista.com> <20020609.213150.32126725.davem@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk "David S. Miller" wrote: > > No mention of what kernel version, what patches applied, etc. > so we cannot help you. Sorry bout that. It is a 2.4.17 kernel and the test is to verify that we have the preempt code right. The question at hand is if this is a likely preempt problem or just a pure overload. The stress on the network is rather high. I would expect that the network code would recover from this sort of thing, so we are looking for a preempt issue at the moment. Still, it could just be the way things work in the 2.4.17 kernel so I thought I would ask. -- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Real time sched: http://sourceforge.net/projects/rtsched/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml From owner-netdev@oss.sgi.com Sun Jun 9 22:08:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5A58XnC023940 for ; Sun, 9 Jun 2002 22:08:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5A58XNI023939 for netdev-outgoing; Sun, 9 Jun 2002 22:08:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5A58VnC023936 for ; Sun, 9 Jun 2002 22:08:31 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id WAA06665; Sun, 9 Jun 2002 22:06:21 -0700 Date: Sun, 09 Jun 2002 22:06:21 -0700 (PDT) Message-Id: <20020609.220621.82407794.davem@redhat.com> To: george@mvista.com Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-net@vger.kernel.org, ak@muc.de, pekkas@netcore.fi Subject: Re: Network oops From: "David S. Miller" In-Reply-To: <3D042F8F.72764243@mvista.com> References: <3D0390E2.1B80ADEE@mvista.com> <20020609.213150.32126725.davem@redhat.com> <3D042F8F.72764243@mvista.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk From: george anzinger Date: Sun, 09 Jun 2002 21:48:15 -0700 I would expect that the network code would recover from this sort of thing, so we are looking for a preempt issue at the moment. Still, it could just be the way things work in the 2.4.17 kernel so I thought I would ask. Even though 2.4.17 is pretty old I still think it's a preempt problem. From owner-netdev@oss.sgi.com Sun Jun 9 22:59:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5A5xWnC024271 for ; Sun, 9 Jun 2002 22:59:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5A5xVbF024270 for netdev-outgoing; Sun, 9 Jun 2002 22:59:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from mark.mielke.cc (IDENT:s+jqvldXF8djaVxIvgpVyvkF26oI2nX+@mark.mielke.cc [216.209.85.42]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5A5xOnC024267 for ; Sun, 9 Jun 2002 22:59:24 -0700 Received: (from mark@localhost) by mark.mielke.cc (8.11.6/8.11.6) id g5A5tgJ22615; Mon, 10 Jun 2002 01:55:42 -0400 Date: Mon, 10 Jun 2002 01:55:42 -0400 From: Mark Mielke To: "David S. Miller" Cc: greearb@candelatech.com, cfriesen@nortelnetworks.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: RFC: per-socket statistics on received/dropped packets Message-ID: <20020610015542.B18388@mark.mielke.cc> References: <3D029DAF.5040006@candelatech.com> <20020608.175108.84748597.davem@redhat.com> <3D039D22.2010805@candelatech.com> <20020609.213440.04716391.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020609.213440.04716391.davem@redhat.com>; from davem@redhat.com on Sun, Jun 09, 2002 at 09:34:40PM -0700 Sender: owner-netdev@oss.sgi.com Precedence: bulk On Sun, Jun 09, 2002 at 09:34:40PM -0700, David S. Miller wrote: > From: Ben Greear > Date: Sun, 09 Jun 2002 11:23:30 -0700 > I need to account for packets on a per-session basis, where a > session endpoint is a UDP port. So, knowing global protocol numbers is > good, but it is not very useful for the detailed accounting I > need. > Why can't you just disable the other UDP services, and then there is > no question which UDP server/client is causing the drops. If the application only had 10 or fewer, non-critical UDP ports sending data, this conclusion might apply. However, even then, this suggestions seems a little silly. "Why don't you call for a full stop and then try them one by one?" is what I read this suggestion as being. > Every argument I hear is one out of lazyness. And that is not a > reason to add something. Simply put, I don't want to add all of this > per-socket counter bumping that only, at best, 1 tenth of 1 percent > of people will use. This means that the rest of the world eats the > overhead just for this small group that actually uses it. Is it 'laziness' that the application needs to be able to minimize every last CPU cycle, or is it 'optimization'? To many designers, the determination that one should *be* lazy is considered a virtue. The opposite extreme would suggest that "well TCP/IP shouldn't be built into the kernel anyways... application writers are just too lazy to implement the TCP/IP stack in user space... it doesn't belong in the kernel..." As for the "rest of the world eats the overhead just for this small group that actually uses it"... this would be true... if every single Linux kernel was built with the exact same configuration. What am I saying? I haven't seen an effective argument against the requirement, and I can see potential uses *for* the requirement. Feel free to provide an effective argument against. :-) Until then... mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From owner-netdev@oss.sgi.com Sun Jun 9 23:06:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5A666nC024441 for ; Sun, 9 Jun 2002 23:06:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5A6662Y024440 for netdev-outgoing; Sun, 9 Jun 2002 23:06:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from grok.yi.org (IDENT:Lk8GG2IOseI05mgzQsqBgPOuy+h6XAC+@ip68-3-14-32.ph.ph.cox.net [68.3.14.32]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5A661nC024437 for ; Sun, 9 Jun 2002 23:06:01 -0700 Received: from candelatech.com (IDENT:sk9j0pKJ+ax2cGuRoCHzEOSaA5nyK8SW@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g5A689L19013; Sun, 9 Jun 2002 23:08:09 -0700 Message-ID: <3D044249.3030406@candelatech.com> Date: Sun, 09 Jun 2002 23:08:09 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: "David S. Miller" CC: mark@mark.mielke.cc, cfriesen@nortelnetworks.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: RFC: per-socket statistics on received/dropped packets References: <3D029DAF.5040006@candelatech.com> <20020608.175108.84748597.davem@redhat.com> <3D039D22.2010805@candelatech.com> <20020609.213440.04716391.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk David S. Miller wrote: > From: Ben Greear > Date: Sun, 09 Jun 2002 11:23:30 -0700 > > I need to account for packets on a per-session basis, where a > session endpoint is a UDP port. So, knowing global protocol numbers is > good, but it is not very useful for the detailed accounting I > need. > > Why can't you just disable the other UDP services, and then there is > no question which UDP server/client is causing the drops. I run multiple connections at once, so this is not a useful alternative. My application is fairly unique, though people doing stuff like RTP and other streaming UDP sessions may be interested in similar counters. > Every argument I hear is one out of lazyness. And that is not a Well, that pretty much finishes this discussion I guess. Thanks, Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From owner-netdev@oss.sgi.com Mon Jun 10 01:10:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5A8AknC026312 for ; Mon, 10 Jun 2002 01:10:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5A8Ajgm026311 for netdev-outgoing; Mon, 10 Jun 2002 01:10:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5A8AdnC026308 for ; Mon, 10 Jun 2002 01:10:39 -0700 Received: from data.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id BAA26019; Mon, 10 Jun 2002 01:09:48 -0700 Received: from mvista.com (IDENT:george@localhost [127.0.0.1]) by data.mvista.com (8.9.3/8.9.3) with ESMTP id BAA31270; Mon, 10 Jun 2002 01:11:01 -0700 Message-ID: <3D045F15.578E1DA9@mvista.com> Date: Mon, 10 Jun 2002 01:11:01 -0700 From: george anzinger Organization: Monta Vista Software X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12-20b i686) X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-net@vger.kernel.org, ak@muc.de, pekkas@netcore.fi Subject: Re: Network oops References: <200205202125.BAA03545@sex.inr.ac.ru> <3D0390E2.1B80ADEE@mvista.com> <20020609.213224.01016187.davem@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk "David S. Miller" wrote: > > Also we need to know what network driver, if preemption is being > used (being from mvista I assume you are using preemption, and if > so make sure you have the preemption networking patches applied). Uh, are you saying there is a set of network patches? If so, where might they be found? And yes, we are testing preemption, trying to wring out the "last" bug :) (Could you be referring to the patches we are developing?) The driver (from the system log): <4>eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html <4>eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin and others <6>eth0: OEM i82557/i82558 10/100 Ethernet, 00:03:47:BD:60:86, IRQ 21. <6> Board assembly fab600-000, Physical connectors present: RJ45 <6> Primary interface chip i82555 PHY #1. <6> General self-test: passed. <6> Serial sub-system self-test: passed. <6> Internal registers self-test: passed. <6> ROM checksum self-test: passed (0xb874c1d3). <6>eth1: OEM i82557/i82558 10/100 Ethernet, 00:03:47:BD:60:87, IRQ 20. <6> Board assembly fab600-000, Physical connectors present: RJ45 <6> Primary interface chip i82555 PHY #1. <6> General self-test: passed. <6> Serial sub-system self-test: passed. <6> Internal registers self-test: passed. <6> ROM checksum self-test: passed (0xb874c1d3). Looks like two NICs. -- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Real time sched: http://sourceforge.net/projects/rtsched/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml From owner-netdev@oss.sgi.com Mon Jun 10 01:33:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5A8XPnC026550 for ; Mon, 10 Jun 2002 01:33:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5A8XOgu026549 for netdev-outgoing; Mon, 10 Jun 2002 01:33:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5A8XMnC026546 for ; Mon, 10 Jun 2002 01:33:22 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id BAA07500; Mon, 10 Jun 2002 01:31:10 -0700 Date: Mon, 10 Jun 2002 01:31:10 -0700 (PDT) Message-Id: <20020610.013110.81671593.davem@redhat.com> To: george@mvista.com Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-net@vger.kernel.org, ak@muc.de, pekkas@netcore.fi Subject: Re: Network oops From: "David S. Miller" In-Reply-To: <3D045F15.578E1DA9@mvista.com> References: <3D0390E2.1B80ADEE@mvista.com> <20020609.213224.01016187.davem@redhat.com> <3D045F15.578E1DA9@mvista.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk From: george anzinger Date: Mon, 10 Jun 2002 01:11:01 -0700 "David S. Miller" wrote: > > Also we need to know what network driver, if preemption is being > used (being from mvista I assume you are using preemption, and if > so make sure you have the preemption networking patches applied). Uh, are you saying there is a set of network patches? If so, where might they be found? And yes, we are testing preemption, trying to wring out the "last" bug :) (Could you be referring to the patches we are developing?) An mvista person recently put "make net preempt safe" patches into 2.5.x Basically it amounted to putting a few preempt_disable sections into net/core/skbuff.c From owner-netdev@oss.sgi.com Mon Jun 10 05:03:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5AC3FnC005234 for ; Mon, 10 Jun 2002 05:03:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5AC3FBM005233 for netdev-outgoing; Mon, 10 Jun 2002 05:03:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5AC3BnC005217 for ; Mon, 10 Jun 2002 05:03:11 -0700 Received: from mira-sjcm-3.cisco.com (IDENT:mirapoint@mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g5AC51IZ027677; Mon, 10 Jun 2002 05:05:01 -0700 (PDT) Received: from ltd-t22.cisco.com (syd-vpn-client-196-52.cisco.com [10.64.196.52]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id AFD02272; Mon, 10 Jun 2002 05:06:05 -0700 (PDT) Message-Id: <5.1.0.14.2.20020610220015.040aff60@mira-sjcm-3.cisco.com> X-Sender: ltd@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 10 Jun 2002 22:03:25 +1000 To: "David S. Miller" From: Lincoln Dale Subject: Re: RFC: per-socket statistics on received/dropped packets Cc: greearb@candelatech.com, mark@mark.mielke.cc, cfriesen@nortelnetworks.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <20020609.213440.04716391.davem@redhat.com> References: <3D039D22.2010805@candelatech.com> <3D029DAF.5040006@candelatech.com> <20020608.175108.84748597.davem@redhat.com> <3D039D22.2010805@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-netdev@oss.sgi.com Precedence: bulk At 09:34 PM 9/06/2002 -0700, David S. Miller wrote: >Every argument I hear is one out of lazyness. And that is not a >reason to add something. Simply put, I don't want to add all of this >per-socket counter bumping that only, at best, 1 tenth of 1 percent >of people will use. This means that the rest of the world eats the >overhead just for this small group that actually uses it. would you be willing to accept a patch that enables per-socket accounting with a CONFIG_ option? to my mind, i can see a number of perfectly valid scenarios. one is for streaming-media applications which could use retransmissions as an indication to buffer more data and/or switch to a different bitrate. another is for a http proxy which has multiple outgoing interfaces which are multihomed via different providers (and some via simplex satellite). retransmissions woud be a nice metric to use for determining the weightings between using different interfaces. cheers, lincoln. From owner-netdev@oss.sgi.com Mon Jun 10 05:20:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5ACKqnC006464 for ; Mon, 10 Jun 2002 05:20:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5ACKq6v006463 for netdev-outgoing; Mon, 10 Jun 2002 05:20:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5ACKnnC006460 for ; Mon, 10 Jun 2002 05:20:49 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id FAA08459; Mon, 10 Jun 2002 05:18:58 -0700 Date: Mon, 10 Jun 2002 05:18:57 -0700 (PDT) Message-Id: <20020610.051857.97850707.davem@redhat.com> To: ltd@cisco.com Cc: greearb@candelatech.com, mark@mark.mielke.cc, cfriesen@nortelnetworks.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: RFC: per-socket statistics on received/dropped packets From: "David S. Miller" In-Reply-To: <5.1.0.14.2.20020610220015.040aff60@mira-sjcm-3.cisco.com> References: <3D039D22.2010805@candelatech.com> <20020609.213440.04716391.davem@redhat.com> <5.1.0.14.2.20020610220015.040aff60@mira-sjcm-3.cisco.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk From: Lincoln Dale Date: Mon, 10 Jun 2002 22:03:25 +1000 would you be willing to accept a patch that enables per-socket accounting with a CONFIG_ option? What is the point? If all the dists will enable it then everybody eats the overhead. If the dists don't enable it, how useful is it and what's so wrong with it being an external patch people just apply when they need to diagnose something like this? From owner-netdev@oss.sgi.com Mon Jun 10 05:28:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5ACSQnC007608 for ; Mon, 10 Jun 2002 05:28:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5ACSQU2007607 for netdev-outgoing; Mon, 10 Jun 2002 05:28:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5ACSLnC007604 for ; Mon, 10 Jun 2002 05:28:21 -0700 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id IAA19790; Mon, 10 Jun 2002 08:30:40 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g5ACOiV22036; Mon, 10 Jun 2002 08:24:44 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 10 Jun 2002 08:24:44 -0400 (EDT) From: jamal To: "David S. Miller" cc: , , , , , Subject: Re: RFC: per-socket statistics on received/dropped packets In-Reply-To: <20020610.051857.97850707.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Mon, 10 Jun 2002, David S. Miller wrote: > From: Lincoln Dale > Date: Mon, 10 Jun 2002 22:03:25 +1000 > > would you be willing to accept a patch that enables per-socket > accounting with a CONFIG_ option? > > What is the point? > > If all the dists will enable it then everybody eats the overhead. > If the dists don't enable it, how useful is it and what's so wrong > with it being an external patch people just apply when they need to > diagnose something like this? > I think i would agree with Dave for it to be an external patch. You really only need this during debugging. I had a similar patch when debugging NAPI about a year ago. I didnt find it that useful after a while because i could deduce the losses from SNMP/netstat output. cheers, jamal From owner-netdev@oss.sgi.com Mon Jun 10 07:01:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5AE17nC015802 for ; Mon, 10 Jun 2002 07:01:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5AE17da015801 for netdev-outgoing; Mon, 10 Jun 2002 07:01:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from mark.mielke.cc (IDENT:nNCoMCbkGyj29kn09mwUdGbz2Wyxhmlx@mark.mielke.cc [216.209.85.42]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5AE0tnC014902 for ; Mon, 10 Jun 2002 07:00:59 -0700 Received: (from mark@localhost) by mark.mielke.cc (8.11.6/8.11.6) id g5ADv3427121; Mon, 10 Jun 2002 09:57:03 -0400 Date: Mon, 10 Jun 2002 09:57:02 -0400 From: Mark Mielke To: jamal Cc: "David S. Miller" , ltd@cisco.com, greearb@candelatech.com, cfriesen@nortelnetworks.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: RFC: per-socket statistics on received/dropped packets Message-ID: <20020610095702.A27037@mark.mielke.cc> References: <20020610.051857.97850707.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from hadi@cyberus.ca on Mon, Jun 10, 2002 at 08:24:44AM -0400 Sender: owner-netdev@oss.sgi.com Precedence: bulk On Mon, Jun 10, 2002 at 08:24:44AM -0400, jamal wrote: > On Mon, 10 Jun 2002, David S. Miller wrote: > > From: Lincoln Dale > > Date: Mon, 10 Jun 2002 22:03:25 +1000 > > would you be willing to accept a patch that enables per-socket > > accounting with a CONFIG_ option? > > What is the point? > > If all the dists will enable it then everybody eats the overhead. > > If the dists don't enable it, how useful is it and what's so wrong > > with it being an external patch people just apply when they need to > > diagnose something like this? > I think i would agree with Dave for it to be an external patch. You > really only need this during debugging. I had a similar patch when > debugging NAPI about a year ago. I didnt find it that useful after > a while because i could deduce the losses from SNMP/netstat output. In your case you found that you could solve it once by debugging the application. This doesn't mean that other applications would not be better at determining the code path to use at execution time. Just because eth1 is behaving perfectly (i.e. low overall dropped UDP packets, or low TCP/IP retransmission) does not mean that a specific socket currently on eth1 heading to China should assume that it can take the 'average' observation as adequate for observing the specific socket. There *are* applications that would benefit from making this decision at run time on a socket-by-socket basis. It is not a common requirement for most desktop users, but it remains a valid requirement. Providing it as a patch, can have the effect that it becomes more trouble than it is worth to grant other people access to the feature, especially from a corporate environment that has signed off on being able to release patches made to Linux back to the Linux source tree. Seems somewhat of a loss... mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From owner-netdev@oss.sgi.com Mon Jun 10 07:11:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5AEBKnC017098 for ; Mon, 10 Jun 2002 07:11:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5AEBK6B017097 for netdev-outgoing; Mon, 10 Jun 2002 07:11:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5AEBFnC017091 for ; Mon, 10 Jun 2002 07:11:15 -0700 Received: from data.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id HAA32521; Mon, 10 Jun 2002 07:10:23 -0700 Received: from mvista.com (IDENT:george@localhost [127.0.0.1]) by data.mvista.com (8.9.3/8.9.3) with ESMTP id HAA29057; Mon, 10 Jun 2002 07:12:04 -0700 Message-ID: <3D04B3B4.DDA3878C@mvista.com> Date: Mon, 10 Jun 2002 07:12:04 -0700 From: george anzinger Organization: Monta Vista Software X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12-20b i686) X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-net@vger.kernel.org, ak@muc.de, pekkas@netcore.fi Subject: Re: Network oops References: <3D0390E2.1B80ADEE@mvista.com> <20020609.213224.01016187.davem@redhat.com> <3D045F15.578E1DA9@mvista.com> <20020610.013110.81671593.davem@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk "David S. Miller" wrote: > > From: george anzinger > Date: Mon, 10 Jun 2002 01:11:01 -0700 > > "David S. Miller" wrote: > > > > Also we need to know what network driver, if preemption is being > > used (being from mvista I assume you are using preemption, and if > > so make sure you have the preemption networking patches applied). > > Uh, are you saying there is a set of network patches? If > so, where might they be found? And yes, we are testing > preemption, trying to wring out the "last" bug :) (Could > you be referring to the patches we are developing?) > > An mvista person recently put "make net preempt safe" patches > into 2.5.x Basically it amounted to putting a few preempt_disable > sections into net/core/skbuff.c Ah, yes. Those are the ones I have found sofar. Robert Love would be the submitter. It would apear there is at least one more hole :( Thus the query. -- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Real time sched: http://sourceforge.net/projects/rtsched/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml From owner-netdev@oss.sgi.com Mon Jun 10 07:41:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5AEf9nC017585 for ; Mon, 10 Jun 2002 07:41:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5AEf9od017584 for netdev-outgoing; Mon, 10 Jun 2002 07:41:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5AEf2nC017576 for ; Mon, 10 Jun 2002 07:41:02 -0700 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5AEh0RY056424; Mon, 10 Jun 2002 10:43:00 -0400 Received: from d04nm108.raleigh.ibm.com (d04nm108.raleigh.ibm.com [9.27.5.84]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5AEg86164240; Mon, 10 Jun 2002 10:42:08 -0400 Subject: Re: Network oops To: george anzinger Cc: ak@muc.de, "David S. Miller" , kuznet@ms2.inr.ac.ru, linux-net@vger.kernel.org, linux-net-owner@vger.kernel.org, netdev@oss.sgi.com, pekkas@netcore.fi X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Mala Anand" Date: Mon, 10 Jun 2002 09:42:10 -0500 X-MIMETrack: Serialize by Router on D04NM108/04/M/IBM(Release 5.0.9a |January 7, 2002) at 06/10/2002 10:42:09 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk >"David S. Miller" wrote: >> >> Also we need to know what network driver, if preemption is being >> used (being from mvista I assume you are using preemption, and if >> so make sure you have the preemption networking patches applied). >Uh, are you saying there is a set of network patches? If >so, where might they be found? And yes, we are testing >preemption, trying to wring out the "last" bug :) (Could >you be referring to the patches we are developing?) >The driver (from the system log): > <4>eepro100.c:v1.09j-t 9/29/99 Donald Becker >http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html > <4>eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by >Andrey V. Savochkin and others > <6>eth0: OEM i82557/i82558 10/100 Ethernet, >00:03:47:BD:60:86, IRQ 21. > <6> Board assembly fab600-000, Physical connectors >present: RJ45 > <6> Primary interface chip i82555 PHY #1. > <6> General self-test: passed. > <6> Serial sub-system self-test: passed. > <6> Internal registers self-test: passed. > <6> ROM checksum self-test: passed (0xb874c1d3). > <6>eth1: OEM i82557/i82558 10/100 Ethernet, >00:03:47:BD:60:87, IRQ 20. > <6> Board assembly fab600-000, Physical connectors >present: RJ45 > <6> Primary interface chip i82555 PHY #1. > <6> General self-test: passed. > <6> Serial sub-system self-test: passed. > <6> Internal registers self-test: passed. > <6> ROM checksum self-test: passed (0xb874c1d3). >Looks like two NICs. -- I have see this problem with this NIC. You need to increase the number of buffers in the RX and TX ring in eepro100.c file. Right now it is set to 32, change it to 256 or 128 this error will go away. Regards, Mala Mala Anand E-mail:manand@us.ibm.com Linux Technology Center - Performance Phone:838-8088; Tie-line:678-8088 From owner-netdev@oss.sgi.com Mon Jun 10 07:49:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5AEn9nC017718 for ; Mon, 10 Jun 2002 07:49:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5AEn90d017717 for netdev-outgoing; Mon, 10 Jun 2002 07:49:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5AEn0nC017714 for ; Mon, 10 Jun 2002 07:49:00 -0700 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id KAA00655; Mon, 10 Jun 2002 10:51:18 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g5AEjVF22696; Mon, 10 Jun 2002 10:45:31 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 10 Jun 2002 10:45:31 -0400 (EDT) From: jamal To: Mark Mielke cc: "David S. Miller" , , , , , Subject: Re: RFC: per-socket statistics on received/dropped packets In-Reply-To: <20020610095702.A27037@mark.mielke.cc> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Mon, 10 Jun 2002, Mark Mielke wrote: > On Mon, Jun 10, 2002 at 08:24:44AM -0400, jamal wrote: > > I think i would agree with Dave for it to be an external patch. You > > really only need this during debugging. I had a similar patch when > > debugging NAPI about a year ago. I didnt find it that useful after > > a while because i could deduce the losses from SNMP/netstat output. > > In your case you found that you could solve it once by debugging the > application. > > This doesn't mean that other applications would not be better at > determining the code path to use at execution time. > > Just because eth1 is behaving perfectly (i.e. low overall dropped UDP > packets, or low TCP/IP retransmission) does not mean that a specific > socket currently on eth1 heading to China should assume that it can > take the 'average' observation as adequate for observing the specific > socket. > > There *are* applications that would benefit from making this decision > at run time on a socket-by-socket basis. It is not a common requirement > for most desktop users, but it remains a valid requirement. > I am confused as to which application needs this, do you have one in mind? AFAIK, UDP/RTP type apps already know how to determine packet loss on a per flow basis. > Providing it as a patch, can have the effect that it becomes more trouble > than it is worth to grant other people access to the feature, especially > from a corporate environment that has signed off on being able to release > patches made to Linux back to the Linux source tree. > You may be confusing technical merit to mean the same thing as corporate donation. In Linux its the later that counts. > Seems somewhat of a loss... Your mileage may vary. Consider this - you have the opp to at least make the patch available. Imagine trying to convince windriver. cheers, jamal > > mark > > -- > mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ > . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder > |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | > | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada > > One ring to rule them all, one ring to find them, one ring to bring them all > and in the darkness bind them... > > http://mark.mielke.cc/ > From owner-netdev@oss.sgi.com Mon Jun 10 08:00:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5AF07nC017946 for ; Mon, 10 Jun 2002 08:00:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5AF078Z017945 for netdev-outgoing; Mon, 10 Jun 2002 08:00:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5AF04nC017942 for ; Mon, 10 Jun 2002 08:00:05 -0700 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id LAA06913; Mon, 10 Jun 2002 11:02:23 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g5AEua122773; Mon, 10 Jun 2002 10:56:37 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 10 Jun 2002 10:56:36 -0400 (EDT) From: jamal To: Mark Mielke cc: "David S. Miller" , , , , , Subject: Re: RFC: per-socket statistics on received/dropped packets In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Mon, 10 Jun 2002, jamal wrote: > You may be confusing technical merit to mean the same thing as corporate > donation. In Linux its the later that counts. Sorry meant the former. cheers, jamal From owner-netdev@oss.sgi.com Mon Jun 10 12:27:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5AJR4nC026504 for ; Mon, 10 Jun 2002 12:27:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5AJR4Ce026503 for netdev-outgoing; Mon, 10 Jun 2002 12:27:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5AJQ2nC026495 for ; Mon, 10 Jun 2002 12:26:02 -0700 Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5AJSED11644; Mon, 10 Jun 2002 15:28:15 -0400 (EDT) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KTYBR6AX; Mon, 10 Jun 2002 15:28:14 -0400 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MSYXG6SA; Mon, 10 Jun 2002 15:28:15 -0400 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 4DCED540E; Mon, 10 Jun 2002 15:28:14 -0400 (EDT) Message-ID: <3D04FDCE.110096E2@nortelnetworks.com> Date: Mon, 10 Jun 2002 15:28:14 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Chris Friesen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-kernel@vger.kernel.org Cc: netdev@oss.sgi.com Subject: Re: RFC: per-socket statistics on received/dropped packets References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk jamal wrote: > > On Mon, 10 Jun 2002, Mark Mielke wrote: > > There *are* applications that would benefit from making this decision > > at run time on a socket-by-socket basis. It is not a common requirement > > for most desktop users, but it remains a valid requirement. > > > > I am confused as to which application needs this, do you have one in mind? > AFAIK, UDP/RTP type apps already know how to determine packet loss > on a per flow basis. The purpose of this patch is to make it reallly easy to nail down exactly how many packets were dropped *per socket*, and for what reason. For me, the information is then used to tune the application statically, but others could use it dynamically. Incoming packets can be dropped at the device, at the device driver, in netif_rx, or at the socket buffer. We've got stats on all of these except for the socket buffer, so why not add them? The cost in the normal case is incrementing a single variable in the socket struct (which is likely already in cache since we're playing with it). I can't see this being that expensive. In the failure path, we get a second increment. Again, this is not going to be noticeable. Sure, you can try and figure out which applications had sockets open, and how many packets they missed, and subtract that from the snmp counters to give how many packets you missed. But to do this you have to lock the box down--isn't it a lot easier to just *know* because you've been keeping track? Chris -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com From owner-netdev@oss.sgi.com Mon Jun 10 14:04:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5AL40nC027794 for ; Mon, 10 Jun 2002 14:04:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5AL40TY027793 for netdev-outgoing; Mon, 10 Jun 2002 14:04:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5AL3unC027790 for ; Mon, 10 Jun 2002 14:03:56 -0700 Received: from cob427.dn.net ([216.167.37.170]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA04230 for ; Mon, 10 Jun 2002 14:06:19 -0700 (PDT) mail_from (radical@corewars.org) Received: from radical.corewars.org ([202.88.151.58]) by cob427.dn.net (8.9.3/8.9.3) with ESMTP id CAA27125 for ; Tue, 11 Jun 2002 02:57:13 +0530 Date: Tue, 11 Jun 2002 02:19:41 +0530 (IST) From: Ankit Jain To: Subject: doc on Networking Implementation in the Linux kernel Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Hi, I am working on a doc on "Networking Subsystem" in the Linux kernel. This is part of the "Linux Kernel documentation project" (www.lkdp.tk). Chapter 2 of this doc is almost complete. I was hoping for some feedback on this doc. Its available at www.corewars.org/~radical/lkdp Only Chapter 2 has been started as of now, its nearing completion. I am looking for feedback on the contents, the general feel of the book, flow.. etc. Any kind of feedback actually. Thank you -Anks From owner-netdev@oss.sgi.com Mon Jun 10 17:03:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5B03DnC000405 for ; Mon, 10 Jun 2002 17:03:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5B03D2J000404 for netdev-outgoing; Mon, 10 Jun 2002 17:03:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from cleanup.comdev.cc (wall.comdev.cc [63.150.62.162]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5B033nC000401 for ; Mon, 10 Jun 2002 17:03:03 -0700 Received: (qmail 14028 invoked from network); 11 Jun 2002 00:05:21 -0000 Received: from rangers.comdev.cc (10.9.1.76) by cleanup.comdev.cc with SMTP; 11 Jun 2002 00:05:21 -0000 Date: Mon, 10 Jun 2002 17:01:48 -0700 (PDT) From: Adam Wozniak To: , , , , , Subject: ipv4 problem w/ eepro100 drivers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On a machine with an 82559ER ethernet chip Linux 2.5.5, with the 6/5/2002 eepro100.c Connect to some other machine via a crossover cable run iperf as a server on both machines run iperf as a client to the server on the other machine (i.e. we want an isolated network, full duplex, full traffic in both directions) [awozniak@rangers ~/linux-2.5.5]$ ksymoops -VKOL -m System239.map < oops239.txt ksymoops 2.4.0 on i686 2.4.2-2. Options used -V (specified) -K (specified) -L (specified) -O (specified) -m System239.map (specified) Unable to handle kernel paging request at virtual address 3938377f c01d1716 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010217 eax: cdc42a08 ebx: 39383736 ecx: 00000004 edx: 00000000 esi: cdc42b10 edi: cdc429a0 ebp: 00000009 esp: c0251ef0 ds: 0018 es: 0018 ss: 0018 Stack: cdc429a0 cdc42b10 cdc42a08 cdc429a0 c01d9dee cdc429a0 00000000 cda8e5c0 00000000 00000001 00000000 cdc429a0 0000e8c8 00000000 00000046 c01d9fc6 cdc429a0 00000001 00000000 c0251fac 00000000 cdc429a0 c01d9f20 c011a933 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f b6 4b 49 45 f6 c1 82 74 0c 31 d2 89 96 70 01 00 00 0f b6 >>EIP; c01d1716 <===== Trace; c01d9dee Trace; c01d9fc6 Trace; c01d9f20 Trace; c011a933 Trace; c011779b Trace; c01176a4 Trace; c01174cb Trace; c0109eac Trace; c0106cc0 Trace; c0106cc0 Trace; c0106cc0 Trace; c0106cc0 Trace; c0106ce4 Trace; c0106d62 Trace; c0105000 <_stext+0/0> Code; c01d1716 00000000 <_EIP>: Code; c01d1716 <===== 0: 0f b6 4b 49 movzbl 0x49(%ebx),%ecx <===== Code; c01d171a 4: 45 inc %ebp Code; c01d171b 5: f6 c1 82 test $0x82,%cl Code; c01d171e 8: 74 0c je 16 <_EIP+0x16> c01d172c Code; c01d1720 a: 31 d2 xor %edx,%edx Code; c01d1722 c: 89 96 70 01 00 00 mov %edx,0x170(%esi) Code; c01d1728 12: 0f b6 00 movzbl (%eax),%eax <0> Kernel panic: Aiee, killing interrupt handler! [awozniak@rangers ~/linux-2.5.5]$ -- Adam Wozniak (KG6GZR) COM DEV Broadband - Digital and Software Systems awozniak@comdev.cc 805 Aerovista Place, San Luis Obispo, CA 93401 http://www.comdev.cc Voice: (805) 544-1089 Fax: (805) 544-2055 From owner-netdev@oss.sgi.com Tue Jun 11 05:28:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BCS4nC010410 for ; Tue, 11 Jun 2002 05:28:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BCS4MX010409 for netdev-outgoing; Tue, 11 Jun 2002 05:28:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BCS1nC010398 for ; Tue, 11 Jun 2002 05:28:02 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id FAA19949; Tue, 11 Jun 2002 05:25:39 -0700 Date: Tue, 11 Jun 2002 05:25:39 -0700 (PDT) Message-Id: <20020611.052539.34960972.davem@redhat.com> To: dent@cosy.sbg.ac.at Cc: ak@muc.de, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: [PATCH][2.5] net/core/dev.c readability cleanups From: "David S. Miller" In-Reply-To: References: X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk I don't find this more readable at all. SUPPORT_2_2 is simply crap, it isn't 2.2.x anything, it simply means protocols that aren't %100 SMP safe. Also "uint" doesn't belong in here and doesn't increase readability at all. Talk to Arnaldo de Melo if you want to do janitorial work in this area, when he sends me cleanups I don't barf. From owner-netdev@oss.sgi.com Tue Jun 11 05:36:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BCaHnC010602 for ; Tue, 11 Jun 2002 05:36:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BCaHQT010601 for netdev-outgoing; Tue, 11 Jun 2002 05:36:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from loewe.cosy.sbg.ac.at (loewe.cosy.sbg.ac.at [141.201.2.12]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BCaBnC010596 for ; Tue, 11 Jun 2002 05:36:12 -0700 Received: from mausmaki.cosy.sbg.ac.at (mausmaki.cosy.sbg.ac.at [141.201.2.18]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with ESMTP id OAA12617; Tue, 11 Jun 2002 14:38:23 +0200 (MET DST) Date: Tue, 11 Jun 2002 14:38:23 +0200 (MET DST) From: "Thomas 'Dent' Mirlacher" To: "David S. Miller" cc: ak@muc.de, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: [PATCH][2.5] net/core/dev.c readability cleanups In-Reply-To: <20020611.052539.34960972.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Tue, 11 Jun 2002, David S. Miller wrote: > I don't find this more readable at all. the special case for deliver_to_old_ones was cluttering the core, imho abstracting it by deliver_to proto improves readability of netif_receive_skb significantly. > SUPPORT_2_2 is simply crap, > it isn't 2.2.x anything, it simply means protocols that aren't %100 > SMP safe. ok, but nevertheless, they should be cleaned up within the 2.5 timeframe. they are not only not 100% SMP safe, they also don't know what to do with skb fragments. > Also "uint" doesn't belong in here and doesn't increase readability at all. good. so it should be "unsigned int" > Talk to Arnaldo de Melo if you want to do janitorial work in this > area, when he sends me cleanups I don't barf. sure, i don't take this as barfing, just like some "honest" opinion. tm -- in some way i do, and in some way i don't. From owner-netdev@oss.sgi.com Tue Jun 11 06:57:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BDvEnC011575 for ; Tue, 11 Jun 2002 06:57:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BDvEDY011574 for netdev-outgoing; Tue, 11 Jun 2002 06:57:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BDvAnC011571 for ; Tue, 11 Jun 2002 06:57:11 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id GAA20289; Tue, 11 Jun 2002 06:54:50 -0700 Date: Tue, 11 Jun 2002 06:54:50 -0700 (PDT) Message-Id: <20020611.065450.50898984.davem@redhat.com> To: dent@cosy.sbg.ac.at Cc: ak@muc.de, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: [PATCH][2.5] net/core/dev.c readability cleanups From: "David S. Miller" In-Reply-To: References: <20020611.052539.34960972.davem@redhat.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk From: "Thomas 'Dent' Mirlacher" Date: Tue, 11 Jun 2002 14:38:23 +0200 (MET DST) i don't take this as barfing, just like some "honest" opinion. Your patch made me barf, that is my opinion. Whether you want to take it or not, that is my honest opinion. To claim that I was dishonest is absurd, how can you know what is inside of my mind? From owner-netdev@oss.sgi.com Tue Jun 11 09:07:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BG7gnC013781 for ; Tue, 11 Jun 2002 09:07:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BG7fXq013780 for netdev-outgoing; Tue, 11 Jun 2002 09:07:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from loewe.cosy.sbg.ac.at (loewe.cosy.sbg.ac.at [141.201.2.12]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BG7ZnC013777 for ; Tue, 11 Jun 2002 09:07:36 -0700 Received: from mausmaki.cosy.sbg.ac.at (mausmaki.cosy.sbg.ac.at [141.201.2.18]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with ESMTP id SAA23837; Tue, 11 Jun 2002 18:09:55 +0200 (MET DST) Date: Tue, 11 Jun 2002 18:09:55 +0200 (MET DST) From: "Thomas 'Dent' Mirlacher" To: "David S. Miller" cc: ak@muc.de, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: [PATCH][2.5] net/core/dev.c readability cleanups In-Reply-To: <20020611.065450.50898984.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk dave, > i don't take this as barfing, just like some "honest" opinion. > > Your patch made me barf, that is my opinion. Whether you want to take > it or not, that is my honest opinion. To claim that I was dishonest > is absurd, how can you know what is inside of my mind? i'm sorry about the lines i've written above, i didn't mean to upset you at all (is was a lack of finding the right word, and using quotes is obviously a bad choice for expressing that) i fully respect your opinion as a person and as the maintainer who's responsible to keep the code clean what i really wanted to express was: i don't take your barfing as an offense, but rather as your opinion and a valueable input on how a patch should look like (but instead i offended you, which was not intended at all) hope i clarified the misunderstanding (/misphrasing), tm -- in some way i do, and in some way i don't. From owner-netdev@oss.sgi.com Tue Jun 11 10:39:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BHdMnC015229 for ; Tue, 11 Jun 2002 10:39:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BHdMQF015228 for netdev-outgoing; Tue, 11 Jun 2002 10:39:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from cleanup.comdev.cc (wall.comdev.cc [63.150.62.162]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BHd5nC015224 for ; Tue, 11 Jun 2002 10:39:06 -0700 Received: (qmail 20485 invoked from network); 11 Jun 2002 17:41:27 -0000 Received: from rangers.comdev.cc (10.9.1.76) by cleanup.comdev.cc with SMTP; 11 Jun 2002 17:41:27 -0000 Date: Tue, 11 Jun 2002 10:37:52 -0700 (PDT) From: Adam Wozniak To: , , , , , cc: Subject: Re: ipv4 problem w/ eepro100 drivers In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk (more info on my problems below, including original email for Donald Becker's benefit) On Mon, 10 Jun 2002, Adam Wozniak wrote: > On a machine with an 82559ER ethernet chip > Linux 2.5.5, with the 6/5/2002 eepro100.c > > Connect to some other machine via a crossover cable > > run iperf as a server on both machines > run iperf as a client to the server on the other machine > > (i.e. we want an isolated network, full duplex, full traffic in both directions) > > [awozniak@rangers ~/linux-2.5.5]$ ksymoops -VKOL -m System239.map < oops239.txt > ksymoops 2.4.0 on i686 2.4.2-2. Options used > -V (specified) > -K (specified) > -L (specified) > -O (specified) > -m System239.map (specified) > > Unable to handle kernel paging request at virtual address 3938377f > c01d1716 > *pde = 00000000 > Oops: 0000 > CPU: 0 > EIP: 0010:[] Not tainted > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010217 > eax: cdc42a08 ebx: 39383736 ecx: 00000004 edx: 00000000 > esi: cdc42b10 edi: cdc429a0 ebp: 00000009 esp: c0251ef0 > ds: 0018 es: 0018 ss: 0018 > Stack: cdc429a0 cdc42b10 cdc42a08 cdc429a0 c01d9dee cdc429a0 00000000 cda8e5c0 > 00000000 00000001 00000000 cdc429a0 0000e8c8 00000000 00000046 c01d9fc6 > cdc429a0 00000001 00000000 c0251fac 00000000 cdc429a0 c01d9f20 c011a933 > Call Trace: [] [] [] [] [] > [] [] [] [] [] [] > [] [] [] [] > Code: 0f b6 4b 49 45 f6 c1 82 74 0c 31 d2 89 96 70 01 00 00 0f b6 > > >>EIP; c01d1716 <===== > Trace; c01d9dee > Trace; c01d9fc6 > Trace; c01d9f20 > Trace; c011a933 > Trace; c011779b > Trace; c01176a4 > Trace; c01174cb > Trace; c0109eac > Trace; c0106cc0 > Trace; c0106cc0 > Trace; c0106cc0 > Trace; c0106cc0 > Trace; c0106ce4 > Trace; c0106d62 > Trace; c0105000 <_stext+0/0> > Code; c01d1716 > 00000000 <_EIP>: > Code; c01d1716 <===== > 0: 0f b6 4b 49 movzbl 0x49(%ebx),%ecx <===== > Code; c01d171a > 4: 45 inc %ebp > Code; c01d171b > 5: f6 c1 82 test $0x82,%cl > Code; c01d171e > 8: 74 0c je 16 <_EIP+0x16> c01d172c > > Code; c01d1720 > a: 31 d2 xor %edx,%edx > Code; c01d1722 > c: 89 96 70 01 00 00 mov %edx,0x170(%esi) > Code; c01d1728 > 12: 0f b6 00 movzbl (%eax),%eax > > <0> Kernel panic: Aiee, killing interrupt handler! > [awozniak@rangers ~/linux-2.5.5]$ (someone asked if we enabled preemptive, we did not) (This bug manifested in several forms. A common one is above. Another common one was a hard lockup of the machine, no oops.) Here are some details about our resolution. Dunno if they help anyone or not. (These comments were not written by me.) } ------- Additional Comments From XXXXXXXXX 2002-06-10 18:41 ------- } } Long story short, they replaced the BIOS on the board (General Software) } with a new one (Award) and we re-ran the test. It came up and ran for } over an hour before we took it down to swap out the eepro100 driver } (see below.) After bringing it back up, it ran again for 50 minutes } until we packed it up and came home. } } After upgrading to the Award BIOS, we started getting an error message } generated by the eepro100 drivers. Something along the lines of "Command } 0x0080 not accepted immediatly, x ticks!" where x is some number larger } than 100. Originally, there was a bug in this reporting code that we } fixed (which required the interruption of the test as stated above. } I needed to load the new module), which reported Command 0x0000 every } time. This code is called when the ethernet chip doesn't respond to a } command very quickly. A "tick" is an undefined amount of time, basically, } how many times it takes to go through a loop waiting for the command to } finish. 100 seems to be an arbitrary number. All the numbers we saw were } less than 110, so its just barely missing the arbitrary cut-off point. } } The interesting bit is that the messages come at about the same interval } as the crashes used to happen. With the PCI bus analizer on the card, } when the system would crash, the Ethernet chip was repeatedly requesting } memory access from the North Bridge, and it kept rejecting it, but neither } would let up. It sorta makes sense that if the chip was programmed one } way by the old BIOS to keep trying and never give up, that it would slam } the bus, but being programmed differently by the new BIOS, it'll retry } or something similar. } } We never found out exactly what WAS happening, and what change in the } BIOS fixed the problem. But we know that the Award BIOS appears to work } and the General Software BIOS does not. -- Adam Wozniak (KG6GZR) COM DEV Broadband - Digital and Software Systems awozniak@comdev.cc 805 Aerovista Place, San Luis Obispo, CA 93401 http://www.comdev.cc Voice: (805) 544-1089 Fax: (805) 544-2055 From owner-netdev@oss.sgi.com Tue Jun 11 15:43:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BMhtnC022602 for ; Tue, 11 Jun 2002 15:43:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BMhtXW022601 for netdev-outgoing; Tue, 11 Jun 2002 15:43:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from gatekeeper.tmr.com (tmr-02.dsl.thebiz.net [216.238.38.204]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BMhmnC022598 for ; Tue, 11 Jun 2002 15:43:48 -0700 Received: from localhost (davidsen@localhost) by gatekeeper.tmr.com (8.9.0/8.9.0) with SMTP id SAA29624; Tue, 11 Jun 2002 18:41:16 -0400 Date: Tue, 11 Jun 2002 18:41:16 -0400 (EDT) From: Bill Davidsen To: "David S. Miller" cc: greearb@candelatech.com, mark@mark.mielke.cc, cfriesen@nortelnetworks.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: RFC: per-socket statistics on received/dropped packets In-Reply-To: <20020609.213440.04716391.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk On Sun, 9 Jun 2002, David S. Miller wrote: > From: Ben Greear > Date: Sun, 09 Jun 2002 11:23:30 -0700 > > I need to account for packets on a per-session basis, where a > session endpoint is a UDP port. So, knowing global protocol numbers is > good, but it is not very useful for the detailed accounting I > need. > > Why can't you just disable the other UDP services, and then there is > no question which UDP server/client is causing the drops. Should be obvious that if a combination of load and client behaviour cause the problem you will learn nothing. > Every argument I hear is one out of lazyness. And that is not a > reason to add something. Simply put, I don't want to add all of this > per-socket counter bumping that only, at best, 1 tenth of 1 percent > of people will use. This means that the rest of the world eats the > overhead just for this small group that actually uses it. Actually your arguments sound like you have a solution to your problem and you want everyone to use it even if it doesn't help them. Have you some emotional tie to SNMP, like being an author? There is no overhead unless the config option is selected, which would be done in a normal kernel source, just as verbose messages, highmem debugging, singing and dancing SYSREQ, debugging SCSI driver, and many, many other features. So the argument against load is totally irrelevant. I can't see why anyone would be against a feature just because they don't personally use it, there is so much stuff of specialized use now, that a it sure sounds like existing practice. I even think that the implementation is general and could be extended to gather other per-connection stats which is a big plus in terms of design quality. -- bill davidsen CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. From owner-netdev@oss.sgi.com Tue Jun 11 18:33:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5C1X7nC024410 for ; Tue, 11 Jun 2002 18:33:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5C1X7eE024409 for netdev-outgoing; Tue, 11 Jun 2002 18:33:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from localhost.localdomain (dsl093-058-082.blt1.dsl.speakeasy.net [66.93.58.82]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5C1X3nC024406 for ; Tue, 11 Jun 2002 18:33:04 -0700 Received: from localhost (becker@localhost) by localhost.localdomain (8.9.3/8.8.7) with ESMTP id VAA02028; Tue, 11 Jun 2002 21:35:23 -0400 Date: Tue, 11 Jun 2002 21:35:23 -0400 (EDT) From: Donald Becker X-X-Sender: To: Mala Anand cc: , , , Subject: Re: Network oops In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 628 Lines: 17 On Mon, 10 Jun 2002, Mala Anand wrote: > I have see this problem with this NIC. You need to increase > the number of buffers in the RX and TX ring in eepro100.c file. > Right now it is set to 32, change it to 256 or 128 this error > will go away. Changing the Tx queue size or number of Rx skbuffs waiting to be filled will not fix a problem. It might mask some problem e.g. a temporary shortage of skbuffs, but it doesn't fix anything. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From owner-netdev@oss.sgi.com Tue Jun 11 20:44:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5C3isnC026430 for ; Tue, 11 Jun 2002 20:44:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5C3isSJ026429 for netdev-outgoing; Tue, 11 Jun 2002 20:44:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5C3ipnC026426 for ; Tue, 11 Jun 2002 20:44:52 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id UAA26124; Tue, 11 Jun 2002 20:41:20 -0700 Date: Tue, 11 Jun 2002 20:41:19 -0700 (PDT) Message-Id: <20020611.204119.58650447.davem@redhat.com> To: davidsen@tmr.com Cc: greearb@candelatech.com, mark@mark.mielke.cc, cfriesen@nortelnetworks.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: RFC: per-socket statistics on received/dropped packets From: "David S. Miller" In-Reply-To: References: <20020609.213440.04716391.davem@redhat.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 563 Lines: 15 From: Bill Davidsen Date: Tue, 11 Jun 2002 18:41:16 -0400 (EDT) Actually your arguments sound like you have a solution to your problem and you want everyone to use it even if it doesn't help them. Have you some emotional tie to SNMP, like being an author? After a comment like this, I have no interest in listening to anything else you have to say. I've been maintaining the Linux networking for 5 or more years now, and the most important thing I do is say no to changes. Franks a lot, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Tue Jun 11 20:54:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5C3sAnC026729 for ; Tue, 11 Jun 2002 20:54:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5C3sA9n026728 for netdev-outgoing; Tue, 11 Jun 2002 20:54:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from conscoop.ottawa.on.ca (cpu2747.adsl.bellglobal.com [207.236.55.216]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5C3s5nC026724 for ; Tue, 11 Jun 2002 20:54:05 -0700 Received: (from rgb@localhost) by conscoop.ottawa.on.ca (8.12.0.Beta5/8.11.1) id g5C3vQtL031359; Tue, 11 Jun 2002 23:57:26 -0400 Date: Tue, 11 Jun 2002 23:57:26 -0400 From: Richard Guy Briggs To: "David S. Miller" Cc: davidsen@tmr.com, greearb@candelatech.com, mark@mark.mielke.cc, cfriesen@nortelnetworks.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: RFC: per-socket statistics on received/dropped packets Message-ID: <20020611235726.P25193@grendel.conscoop.ottawa.on.ca> References: <20020609.213440.04716391.davem@redhat.com> <20020611.204119.58650447.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020611.204119.58650447.davem@redhat.com>; from davem@redhat.com on Tue, Jun 11, 2002 at 08:41:19PM -0700 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1304 Lines: 30 On Tue, Jun 11, 2002 at 08:41:19PM -0700, David S. Miller wrote: > From: Bill Davidsen > Date: Tue, 11 Jun 2002 18:41:16 -0400 (EDT) > > Actually your arguments sound like you have a solution to your problem > and you want everyone to use it even if it doesn't help them. Have you > some emotional tie to SNMP, like being an author? Basically Bill, if you don't like this policy, fork the code. That is one of the strengths (and weaknesses) of open source. If your tree works better and gets wider use, then something about it must be better. If not, then maybe it wasn't. This community works on reputation capital (and some diplomacy). > After a comment like this, I have no interest in listening to anything > else you have to say. I've been maintaining the Linux networking for > 5 or more years now, and the most important thing I do is say no to > changes. > > Franks a lot, > David S. Miller > davem@redhat.com slainte mhath, RGB -- Richard Guy Briggs -- ~\ Auto-Free Ottawa! Canada -- \@ @ No Internet Wiretapping! -- _\\/\%___\\/\% Vote! -- _______GTVS6#790__(*)_______(*)(*)_______ From owner-netdev@oss.sgi.com Tue Jun 11 22:25:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5C5P2nC027316 for ; Tue, 11 Jun 2002 22:25:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5C5P2MT027315 for netdev-outgoing; Tue, 11 Jun 2002 22:25:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from mark.mielke.cc (IDENT:vY6omuRmx4E/X1t5KoQWyrSH5b5PJrpv@mark.mielke.cc [216.209.85.42]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5C5OsnC027310 for ; Tue, 11 Jun 2002 22:24:55 -0700 Received: (from mark@localhost) by mark.mielke.cc (8.11.6/8.11.6) id g5C5K4615866; Wed, 12 Jun 2002 01:20:04 -0400 Date: Wed, 12 Jun 2002 01:20:04 -0400 From: Mark Mielke To: Richard Guy Briggs Cc: "David S. Miller" , davidsen@tmr.com, greearb@candelatech.com, cfriesen@nortelnetworks.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: RFC: per-socket statistics on received/dropped packets Message-ID: <20020612012004.A15773@mark.mielke.cc> References: <20020609.213440.04716391.davem@redhat.com> <20020611.204119.58650447.davem@redhat.com> <20020611235726.P25193@grendel.conscoop.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020611235726.P25193@grendel.conscoop.ottawa.on.ca>; from rgb@conscoop.ottawa.on.ca on Tue, Jun 11, 2002 at 11:57:26PM -0400 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2595 Lines: 59 On Tue, Jun 11, 2002 at 11:57:26PM -0400, Richard Guy Briggs wrote: > On Tue, Jun 11, 2002 at 08:41:19PM -0700, David S. Miller wrote: > > From: Bill Davidsen > > Date: Tue, 11 Jun 2002 18:41:16 -0400 (EDT) > > Actually your arguments sound like you have a solution to your problem > > and you want everyone to use it even if it doesn't help them. Have you > > some emotional tie to SNMP, like being an author? > Basically Bill, if you don't like this policy, fork the code. That is > one of the strengths (and weaknesses) of open source. If your tree > works better and gets wider use, then something about it must be better. > If not, then maybe it wasn't. This community works on reputation > capital (and some diplomacy). To some degree (i.e. I know it is not intentional), this comes across as blackmail. Sorta like "if you want to play ball with me, you play by my rules, otherwise you can go find your own diamond and your own friends to play with." I would still like to see David's logic as to why the approach is bad. So far it amounts to 1) David doesn't like it, 2) David doesn't see a need for it, or can see other less adequate methods of approximating the same effect, and 3) David suspects that it will effect the performance of all users to provide a limited gain for some applications. 'Reputation capital' is earned. I would like to see it 'earned' in practice given a real requirement from a real developer on a real world class application. Statements such as 'the most important thing I do is say no', don't convince me that a reputation is deserved. The extreme of this is that an automaton could say no to everything. Yes, I might be testing David... is it fair? Well, the requirement was fair, so how could it not be fair? I (and Bill) are just asking for some logic to show us where we are wrong. Linus can pull the "I'm god, and that's that" gig. Fine. How far does the godhead extend? Who else can pull this gig? I am waiting in anticipation to be shown the error of my ways using proper logic and iron clad reasoning... :-) Cheers, mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From owner-netdev@oss.sgi.com Tue Jun 11 23:06:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5C66knC027705 for ; Tue, 11 Jun 2002 23:06:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5C66k73027704 for netdev-outgoing; Tue, 11 Jun 2002 23:06:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5C66dnC027695 for ; Tue, 11 Jun 2002 23:06:40 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5C68tv29915; Wed, 12 Jun 2002 09:08:55 +0300 Date: Wed, 12 Jun 2002 09:08:55 +0300 (EEST) From: Pekka Savola To: Mark Mielke cc: linux-kernel@vger.kernel.org, Subject: Re: RFC: per-socket statistics on received/dropped packets In-Reply-To: <20020612012004.A15773@mark.mielke.cc> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2018 Lines: 43 On Wed, 12 Jun 2002, Mark Mielke wrote: > On Tue, Jun 11, 2002 at 11:57:26PM -0400, Richard Guy Briggs wrote: > > On Tue, Jun 11, 2002 at 08:41:19PM -0700, David S. Miller wrote: > > > From: Bill Davidsen > > > Date: Tue, 11 Jun 2002 18:41:16 -0400 (EDT) > > > Actually your arguments sound like you have a solution to your problem > > > and you want everyone to use it even if it doesn't help them. Have you > > > some emotional tie to SNMP, like being an author? > > Basically Bill, if you don't like this policy, fork the code. That is > > one of the strengths (and weaknesses) of open source. If your tree > > works better and gets wider use, then something about it must be better. > > If not, then maybe it wasn't. This community works on reputation > > capital (and some diplomacy). > > To some degree (i.e. I know it is not intentional), this comes across as > blackmail. > > Sorta like "if you want to play ball with me, you play by my rules, > otherwise you can go find your own diamond and your own friends to > play with." > > I would still like to see David's logic as to why the approach is bad. > > So far it amounts to 1) David doesn't like it, 2) David doesn't see a need > for it, or can see other less adequate methods of approximating the same > effect, and 3) David suspects that it will effect the performance of all > users to provide a limited gain for some applications. Just to chime in my support (not that I don't think anyone needs it), I think socket-based counters are An Extremely Bad Idea. They might be useful in some rather specific debugging scenarios (like 100's on debugging printk's too!), but definitely not something we want to be cluttering the main tree with, _especially_ before they've shown their worth (doubtful). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Tue Jun 11 23:24:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5C6OTnC028001 for ; Tue, 11 Jun 2002 23:24:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5C6OT4c028000 for netdev-outgoing; Tue, 11 Jun 2002 23:24:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from grok.yi.org (IDENT:7X0eV6c9mP0c/Nxddzppr6tKHYLQCcK+@ip68-3-14-32.ph.ph.cox.net [68.3.14.32]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5C6ONnC027997 for ; Tue, 11 Jun 2002 23:24:23 -0700 Received: from candelatech.com (IDENT:LWCBYNUl8P13icwOBf6Upo3kfgIo4eV0@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g5C6QeL28306; Tue, 11 Jun 2002 23:26:40 -0700 Message-ID: <3D06E9A0.5060801@candelatech.com> Date: Tue, 11 Jun 2002 23:26:40 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Pekka Savola CC: Mark Mielke , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: RFC: per-socket statistics on received/dropped packets References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1326 Lines: 41 Pekka Savola wrote: > Just to chime in my support (not that I don't think anyone needs it), I > think socket-based counters are An Extremely Bad Idea. Several folks have produced arguments with details showing how they can use the counters to better their product and/or debugging. Just waving your hands and saying you don't like it does not invalidate their claims. Please go back and read the thread and then, if you're able, put forth some valid arguments for how to accomplish the goals in some other manner, or show the negatives of including the feature. If they are useful to some people, and have zero performance affect on others (due to being a configurable kernel feature), then what is your complaint? I see two reasons left to dislike this feature: 1) General increase in #ifdef'd code. This actually seems like a pretty good argument, but I haven't seen anyone mention it specifically. 2) General dislike for a feature that one personally has no use for. Seems to be Dave's main (professed) excuse. Please add to this list, but back up your claims. Thanks, Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From owner-netdev@oss.sgi.com Tue Jun 11 23:30:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5C6UmnC028147 for ; Tue, 11 Jun 2002 23:30:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5C6UlxW028146 for netdev-outgoing; Tue, 11 Jun 2002 23:30:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5C6UhnC028140 for ; Tue, 11 Jun 2002 23:30:44 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5C6Wws30171; Wed, 12 Jun 2002 09:32:58 +0300 Date: Wed, 12 Jun 2002 09:32:58 +0300 (EEST) From: Pekka Savola To: Ben Greear cc: Mark Mielke , , Subject: Re: RFC: per-socket statistics on received/dropped packets In-Reply-To: <3D06E9A0.5060801@candelatech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 910 Lines: 24 On Tue, 11 Jun 2002, Ben Greear wrote: > If they are useful to some people, and have zero performance affect on others > (due to being a configurable kernel feature), then what is your > complaint? 3) Added features and complexity makes it more difficult to maintain the kernel (you could say this is a variant of 1) 4) Patches that have only a little debugging/etc. value are probably useful, but mainly for a specific set of people, and this would seem to be best handled by external patches. > 1) General increase in #ifdef'd code. This actually seems like > a pretty good argument, but I haven't seen anyone mention it > specifically. Always implied from maintenance point-of-view. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Tue Jun 11 23:47:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5C6lBnC028337 for ; Tue, 11 Jun 2002 23:47:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5C6lB9Q028336 for netdev-outgoing; Tue, 11 Jun 2002 23:47:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from grok.yi.org (IDENT:kkz2s1J/e48Uap6k3nVG1YuKabYFxpNE@ip68-3-14-32.ph.ph.cox.net [68.3.14.32]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5C6l5nC028333 for ; Tue, 11 Jun 2002 23:47:05 -0700 Received: from candelatech.com (IDENT:38mttOomZDYLmVyUZ1EZKXEUWwiZeE0n@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g5C6nOL29491; Tue, 11 Jun 2002 23:49:24 -0700 Message-ID: <3D06EEF3.3090103@candelatech.com> Date: Tue, 11 Jun 2002 23:49:23 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Pekka Savola CC: Mark Mielke , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: RFC: per-socket statistics on received/dropped packets References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1254 Lines: 42 Pekka Savola wrote: > On Tue, 11 Jun 2002, Ben Greear wrote: > >>If they are useful to some people, and have zero performance affect on others >>(due to being a configurable kernel feature), then what is your >>complaint? >> > > 3) Added features and complexity makes it more difficult to maintain the > kernel (you could say this is a variant of 1) Adding counters to structures generally is not going to increase complexity (especially when you comment the code). It would increase the code size slightly. The code to bump the counters should also be extremely simple (surely we don't drop packets in more than just a few places). So, in this case, the increase in complexity seems pretty minimal. > 4) Patches that have only a little debugging/etc. value are probably > useful, but mainly for a specific set of people, and this would seem to be > best handled by external patches. External-only patches almost always rot, and are extremely hard to really share across organizations. Still, point taken. Thanks, Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From owner-netdev@oss.sgi.com Wed Jun 12 02:15:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5C9FDnC032217 for ; Wed, 12 Jun 2002 02:15:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5C9FD9R032216 for netdev-outgoing; Wed, 12 Jun 2002 02:15:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pookie.dev.sportingbet.com (IDENT:Oujgp64bQ9ovcvbm@[195.157.147.30]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5C9F3nC032213 for ; Wed, 12 Jun 2002 02:15:04 -0700 Received: (qmail 26871 invoked from network); 12 Jun 2002 09:06:33 -0000 Received: from bart.dev.sportingbet.com (HELO dev.sportingbet.com) (192.168.2.152) by pookie.dev.sportingbet.com with SMTP; 12 Jun 2002 09:06:33 -0000 Received: (qmail 21254 invoked by uid 500); 12 Jun 2002 09:18:25 -0000 Date: Wed, 12 Jun 2002 10:18:25 +0100 From: Sean Hunter To: Mark Mielke Cc: Richard Guy Briggs , "David S. Miller" , davidsen@tmr.com, greearb@candelatech.com, cfriesen@nortelnetworks.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: RFC: per-socket statistics on received/dropped packets Message-ID: <20020612101825.E17812@dev.sportingbet.com> Mail-Followup-To: Sean Hunter , Mark Mielke , Richard Guy Briggs , "David S. Miller" , davidsen@tmr.com, greearb@candelatech.com, cfriesen@nortelnetworks.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com References: <20020609.213440.04716391.davem@redhat.com> <20020611.204119.58650447.davem@redhat.com> <20020611235726.P25193@grendel.conscoop.ottawa.on.ca> <20020612012004.A15773@mark.mielke.cc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020612012004.A15773@mark.mielke.cc>; from mark@mark.mielke.cc on Wed, Jun 12, 2002 at 01:20:04AM -0400 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 3044 Lines: 70 On Wed, Jun 12, 2002 at 01:20:04AM -0400, Mark Mielke wrote: > On Tue, Jun 11, 2002 at 11:57:26PM -0400, Richard Guy Briggs wrote: > > Basically Bill, if you don't like this policy, fork the code. That > > is one of the strengths (and weaknesses) of open source. If your > > tree works better and gets wider use, then something about it must > > be better. If not, then maybe it wasn't. This community works on > > reputation capital (and some diplomacy). > > To some degree (i.e. I know it is not intentional), this comes across > as blackmail. > > Sorta like "if you want to play ball with me, you play by my rules, > otherwise you can go find your own diamond and your own friends to > play with." > > I would still like to see David's logic as to why the approach is bad. Perhaps the reason David Miller is the network stack maintainer is that he can see things that you can't see? The onus is on you (as proposer) to show _him_ that a change is worthwhile, not the other way round. Don't be confused into thinking this is some sort of democracy. > So far it amounts to 1) David doesn't like it, 2) David doesn't see a > need for it, or can see other less adequate methods of approximating > the same effect, and 3) David suspects that it will effect the > performance of all users to provide a limited gain for some > applications. Yup. What you've left out is: 4)David has demonstrated that he knows his stuff by high-quality work over a long period of time 5)You haven't. 6)Because he is the network maintainer you need to convince him and you haven't done so. > 'Reputation capital' is earned. I would like to see it 'earned' in > practice given a real requirement from a real developer on a real > world class application. > > Statements such as 'the most important thing I do is say no', don't > convince me that a reputation is deserved. The extreme of this is that > an automaton could say no to everything. Bollocks. Its plainly ridiculous to impugne David Miller and imply his reputation isn't earned. You or I or your straw automaton could say "no", but it doesn't mean anyone will listen. Furthermore, I would propose that the Linux TCP/IP networking stack is "world class" and has earned David Miller (and others) a fair bit of "reputation capital", and that's why he (and not you or I) is where he is. > Yes, I might be testing David... is it fair? Well, the requirement was > fair, so how could it not be fair? > > I (and Bill) are just asking for some logic to show us where we are > wrong. Linus can pull the "I'm god, and that's that" gig. Fine. How > far does the godhead extend? Who else can pull this gig? Show why it should be in the main tree and not just a debugging patch. > I am waiting in anticipation to be shown the error of my ways using > proper logic and iron clad reasoning... :-) I think its more like Dave M et al are waiting for someone to show the slightest bit of evidence to say this isn't better off as just a debugging patch rather than just waving hands and talking bollocks. Sean From owner-netdev@oss.sgi.com Wed Jun 12 05:09:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5CC9UnC013167 for ; Wed, 12 Jun 2002 05:09:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CC9UPF013166 for netdev-outgoing; Wed, 12 Jun 2002 05:09:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pincoya.inf.utfsm.cl (IDENT:root@pincoya.inf.utfsm.cl [200.1.19.3]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CC9NnC013162 for ; Wed, 12 Jun 2002 05:09:24 -0700 Received: from pincoya.inf.utfsm.cl (IDENT:vonbrand@localhost.inf.utfsm.cl [127.0.0.1]) by pincoya.inf.utfsm.cl (8.12.3/8.12.3) with ESMTP id g5CCBk7i030146; Wed, 12 Jun 2002 08:11:46 -0400 Received: from pincoya.inf.utfsm.cl (vonbrand@localhost) by pincoya.inf.utfsm.cl (8.12.3/8.12.3) with ESMTP id g5CCBjZt030139; Wed, 12 Jun 2002 08:11:45 -0400 Message-Id: <200206121211.g5CCBjZt030139@pincoya.inf.utfsm.cl> To: Ben Greear cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: RFC: per-socket statistics on received/dropped packets In-Reply-To: Message from Ben Greear of "Tue, 11 Jun 2002 23:26:40 MST." <3D06E9A0.5060801@candelatech.com> Date: Wed, 12 Jun 2002 08:11:45 -0400 From: Horst von Brand Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1264 Lines: 34 [Cc:'s stripped] Ben Greear said: > Pekka Savola wrote: > > Just to chime in my support (not that I don't think anyone needs it), I > > think socket-based counters are An Extremely Bad Idea. [...] > If they are useful to some people, and have zero performance affect on others > (due to being a configurable kernel feature), then what is your > complaint? That it adds code, which impacts _everybody_ futzing around in that area, specially if it is a configurable option (this means multiplying the possible configurations to be tested). > I see two reasons left to dislike this feature: > > 1) General increase in #ifdef'd code. This actually seems like > a pretty good argument, but I haven't seen anyone mention it > specifically. Right. > 2) General dislike for a feature that one personally has no use for. > Seems to be Dave's main (professed) excuse. General dislike for adding features of _extremely_ limited (debugging!) use? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From owner-netdev@oss.sgi.com Wed Jun 12 05:27:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5CCRtnC014103 for ; Wed, 12 Jun 2002 05:27:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CCRtXW014102 for netdev-outgoing; Wed, 12 Jun 2002 05:27:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CCRnnC014099 for ; Wed, 12 Jun 2002 05:27:49 -0700 Received: from mira-sjcm-3.cisco.com (IDENT:mirapoint@mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g5CCTcuF003293; Wed, 12 Jun 2002 05:29:38 -0700 (PDT) Received: from ltd-t22.cisco.com (syd-vpn-client-194-31.cisco.com [10.64.194.31]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id AFD61120; Wed, 12 Jun 2002 05:31:04 -0700 (PDT) Message-Id: <5.1.0.14.2.20020612221925.0283fb18@mira-sjcm-3.cisco.com> X-Sender: ltd@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 12 Jun 2002 22:28:15 +1000 To: Horst von Brand , "David S. Miller" From: Lincoln Dale Subject: Re: RFC: per-socket statistics on received/dropped packets Cc: Ben Greear , linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <200206121211.g5CCBjZt030139@pincoya.inf.utfsm.cl> References: <3D06E9A0.5060801@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 944 Lines: 28 At 08:11 AM 12/06/2002 -0400, Horst von Brand wrote: >General dislike for adding features of _extremely_ limited (debugging!) use? i would imagine that every installation of Squid on linux is interested in having _realistic transaction logs_ of exactly how much data was received and transmitted on a TCP connection. i know of many many folk who use transaction logs from HTTP caches for volume-based billing. right now, those bills are anywhere between 10% to 25% incorrect. you call that "extremely limited"? of course, i am doing exactly what Dave said to do -- maintaining my own out-of-kernel patch -- but its a pain, i'm sure it will soon conflict with stuff and is a damn shame - it isn't much code, but Dave seems pretty steadfast that he isn't interested. damn shame that. i think the information is on par with getsockopt(..,TCP_INFO,..) in terms of usefulness yet TCP_INFO is there in the kernel. cheers, lincoln. From owner-netdev@oss.sgi.com Wed Jun 12 05:37:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5CCb5nC014302 for ; Wed, 12 Jun 2002 05:37:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CCb5oN014301 for netdev-outgoing; Wed, 12 Jun 2002 05:37:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CCaxnC014298 for ; Wed, 12 Jun 2002 05:37:00 -0700 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id IAA20698; Wed, 12 Jun 2002 08:39:27 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g5CCXRQ00845; Wed, 12 Jun 2002 08:33:27 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Wed, 12 Jun 2002 08:33:26 -0400 (EDT) From: jamal To: Lincoln Dale cc: Horst von Brand , "David S. Miller" , Ben Greear , , Subject: Re: RFC: per-socket statistics on received/dropped packets In-Reply-To: <5.1.0.14.2.20020612221925.0283fb18@mira-sjcm-3.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1179 Lines: 35 On Wed, 12 Jun 2002, Lincoln Dale wrote: > At 08:11 AM 12/06/2002 -0400, Horst von Brand wrote: > >General dislike for adding features of _extremely_ limited (debugging!) use? > > i would imagine that every installation of Squid on linux is interested in > having _realistic transaction logs_ of exactly how much data was received > and transmitted on a TCP connection. > > i know of many many folk who use transaction logs from HTTP caches for > volume-based billing. > right now, those bills are anywhere between 10% to 25% incorrect. > > you call that "extremely limited"? > Surely, you must have better ways to do accounting than this -- otherwise you deserve to loose money. > > of course, i am doing exactly what Dave said to do -- maintaining my own > out-of-kernel patch -- but its a pain, i'm sure it will soon conflict with > stuff and is a damn shame - it isn't much code, but Dave seems pretty > steadfast that he isn't interested. > You havent proven why its needed. And from the looks of it you dont even need it. If 3 people need it, then i would like to ask we add lawn mower support that my relatives have been asking for the last 5 years. cheers, jamal From owner-netdev@oss.sgi.com Wed Jun 12 07:58:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5CEwInC017244 for ; Wed, 12 Jun 2002 07:58:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CEwI00017243 for netdev-outgoing; Wed, 12 Jun 2002 07:58:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from mark.mielke.cc (IDENT:25243qCsKDj/WEUPj+vAXgCGTtbGHlKB@mark.mielke.cc [216.209.85.42]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CEw9nC017240 for ; Wed, 12 Jun 2002 07:58:10 -0700 Received: (from mark@localhost) by mark.mielke.cc (8.11.6/8.11.6) id g5CErtU20907; Wed, 12 Jun 2002 10:53:55 -0400 Date: Wed, 12 Jun 2002 10:53:55 -0400 From: Mark Mielke To: jamal Cc: Lincoln Dale , Horst von Brand , "David S. Miller" , Ben Greear , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: RFC: per-socket statistics on received/dropped packets Message-ID: <20020612105355.A20760@mark.mielke.cc> References: <5.1.0.14.2.20020612224038.0251bd08@mira-sjcm-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from hadi@cyberus.ca on Wed, Jun 12, 2002 at 09:00:08AM -0400 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2368 Lines: 51 On Wed, Jun 12, 2002 at 09:00:08AM -0400, jamal wrote: > On Wed, 12 Jun 2002, Lincoln Dale wrote: > > At 08:33 AM 12/06/2002 -0400, jamal wrote: > > >If 3 people need it, then i would like to ask we add lawn mower > > >support that my relatives have been asking for the last 5 years. > > lawn-mower support sounds like a userspace application to me. > But we need a new system call support This is another non-argument not dissimilar to the method of arguing that David has used up to this point. If lawn-mower support (whatever that is) is something that people would use, then perhaps it *should* be added, even if it needs a new system call. You have not shown a valid argument against your own sarcastic suggestion, other than an implicit sneer. There is no evidence that only three people would use a feature that allows one to measure the exact bandwidth being used by a specific TCP/IP connection (including retransmissions). There is evidence that if such a patch was not accepted into the kernel that people that desired this feature would either reinvent the wheel, because they could not locate the private patch, likely doing it *wrong* because they did not have wonderful people such as David to make strategic suggestions regarding the exact implementation, or that they would find other less adequate ways of doing something that approximates what they actually need using existing functionality. Anyways... I'll drop out of this one as my presence here was only to try to encourage creativity, not to create any anger. I never intended to slight David. I would like to see stronger arguments presented when saying no to a feature, as they allow me, and others around here, to learn. Cliche's don't teach me anything, and they make the speaker appear less qualified. (Appearance may != Reality) Good work David, and I look forward to seeing clearer objections. mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From owner-netdev@oss.sgi.com Wed Jun 12 08:01:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5CF1YnC017671 for ; Wed, 12 Jun 2002 08:01:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CF1Yik017670 for netdev-outgoing; Wed, 12 Jun 2002 08:01:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CF1QnC017667 for ; Wed, 12 Jun 2002 08:01:27 -0700 Received: from demexg11.emea.cpqcorp.net (demexg11.emea.cpqcorp.net [16.41.94.66]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 59FB4737; Wed, 12 Jun 2002 08:11:41 -0700 (PDT) Received: from aeoexc01.emea.cpqcorp.net ([16.188.69.255]) by demexg11.emea.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Jun 2002 17:03:13 +0200 Received: from mail pickup service by aeoexc01.emea.cpqcorp.net with Microsoft SMTPSVC; Wed, 12 Jun 2002 17:03:12 +0200 Received: from demexb11.emea.cpqcorp.net ([16.41.94.50]) by aeoexc01.emea.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Jun 2002 17:03:12 +0200 Received: from cceexb11.americas.cpqcorp.net ([16.110.250.162]) by demexb11.emea.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Jun 2002 17:03:11 +0200 Received: from cceexg11.americas.cpqcorp.net ([16.110.250.125]) by cceexb11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Jun 2002 10:03:05 -0500 Received: from ztxmail01.ztx.compaq.com ([161.114.8.205]) by cceexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Jun 2002 10:03:04 -0500 Received: from postal.hp.com (postal.hp.com [192.151.81.11]) by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id C1DAB615 for ; Wed, 12 Jun 2002 10:03:03 -0500 (CDT) Received: from vger.kernel.org (vger.kernel.org [209.116.70.75]) by postal.hp.com (Postfix) with ESMTP id 06CF21F544 for ; Wed, 12 Jun 2002 08:02:26 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 12 Jun 2002 11:00:37 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 12 Jun 2002 11:00:36 -0400 Received: from mark.mielke.cc ([216.209.85.42]:50951 "EHLO mark.mielke.cc") by vger.kernel.org with ESMTP id ; Wed, 12 Jun 2002 11:00:35 -0400 Received: (from mark@localhost) by mark.mielke.cc (8.11.6/8.11.6) id g5CErtU20907; Wed, 12 Jun 2002 10:53:55 -0400 Date: Wed, 12 Jun 2002 10:53:55 -0400 From: Mark Mielke To: jamal Cc: Lincoln Dale , Horst von Brand , "David S. Miller" , Ben Greear , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: RFC: per-socket statistics on received/dropped packets Message-ID: <20020612105355.A20760@mark.mielke.cc> References: <5.1.0.14.2.20020612224038.0251bd08@mira-sjcm-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from hadi@cyberus.ca on Wed, Jun 12, 2002 at 09:00:08AM -0400 X-Mailing-List: linux-kernel@vger.kernel.org X-OriginalArrivalTime: 12 Jun 2002 15:03:05.0065 (UTC) FILETIME=[4120C590:01C21222] Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2611 Lines: 56 On Wed, Jun 12, 2002 at 09:00:08AM -0400, jamal wrote: > On Wed, 12 Jun 2002, Lincoln Dale wrote: > > At 08:33 AM 12/06/2002 -0400, jamal wrote: > > >If 3 people need it, then i would like to ask we add lawn mower > > >support that my relatives have been asking for the last 5 years. > > lawn-mower support sounds like a userspace application to me. > But we need a new system call support This is another non-argument not dissimilar to the method of arguing that David has used up to this point. If lawn-mower support (whatever that is) is something that people would use, then perhaps it *should* be added, even if it needs a new system call. You have not shown a valid argument against your own sarcastic suggestion, other than an implicit sneer. There is no evidence that only three people would use a feature that allows one to measure the exact bandwidth being used by a specific TCP/IP connection (including retransmissions). There is evidence that if such a patch was not accepted into the kernel that people that desired this feature would either reinvent the wheel, because they could not locate the private patch, likely doing it *wrong* because they did not have wonderful people such as David to make strategic suggestions regarding the exact implementation, or that they would find other less adequate ways of doing something that approximates what they actually need using existing functionality. Anyways... I'll drop out of this one as my presence here was only to try to encourage creativity, not to create any anger. I never intended to slight David. I would like to see stronger arguments presented when saying no to a feature, as they allow me, and others around here, to learn. Cliche's don't teach me anything, and they make the speaker appear less qualified. (Appearance may != Reality) Good work David, and I look forward to seeing clearer objections. mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From owner-netdev@oss.sgi.com Wed Jun 12 09:01:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5CG1CnC021813 for ; Wed, 12 Jun 2002 09:01:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CG1CEY021812 for netdev-outgoing; Wed, 12 Jun 2002 09:01:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CG16nC021806 for ; Wed, 12 Jun 2002 09:01:07 -0700 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id MAA13866; Wed, 12 Jun 2002 12:03:33 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g5CFvkh01670; Wed, 12 Jun 2002 11:57:46 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Wed, 12 Jun 2002 11:57:45 -0400 (EDT) From: jamal To: Mark Mielke cc: Lincoln Dale , Horst von Brand , "David S. Miller" , Ben Greear , , Subject: Re: RFC: per-socket statistics on received/dropped packets In-Reply-To: <20020612105355.A20760@mark.mielke.cc> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 978 Lines: 27 On Wed, 12 Jun 2002, Mark Mielke wrote: > On Wed, Jun 12, 2002 at 09:00:08AM -0400, jamal wrote: > > On Wed, 12 Jun 2002, Lincoln Dale wrote: > > > At 08:33 AM 12/06/2002 -0400, jamal wrote: > > > >If 3 people need it, then i would like to ask we add lawn mower > > > >support that my relatives have been asking for the last 5 years. > > > lawn-mower support sounds like a userspace application to me. > > But we need a new system call support > > This is another non-argument not dissimilar to the method of arguing that > David has used up to this point. > > If lawn-mower support (whatever that is) is something that people > would use, then perhaps it *should* be added, even if it needs a new > system call. You have not shown a valid argument against your own > sarcastic suggestion, other than an implicit sneer. > It was meant to be humorous. I am sure Lincoln meant it that way as well. Next time i'll put a smiley. How about hairdryer support? ;-> cheers, jamal From owner-netdev@oss.sgi.com Wed Jun 12 09:56:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5CGu4nC022712 for ; Wed, 12 Jun 2002 09:56:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CGu3ra022711 for netdev-outgoing; Wed, 12 Jun 2002 09:56:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CGtxnC022708 for ; Wed, 12 Jun 2002 09:55:59 -0700 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5CGwQRY139062; Wed, 12 Jun 2002 12:58:26 -0400 Received: from d04nm108.raleigh.ibm.com (d04nm108.raleigh.ibm.com [9.27.5.84]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5CGwQ231586; Wed, 12 Jun 2002 12:58:26 -0400 Subject: Re: Network oops To: Donald Becker Cc: linux-net@vger.kernel.org, linux-net-owner@vger.kernel.org, netdev@oss.sgi.com, pekkas@netcore.fi X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Mala Anand" Date: Wed, 12 Jun 2002 11:58:30 -0500 X-MIMETrack: Serialize by Router on D04NM108/04/M/IBM(Release 5.0.9a |January 7, 2002) at 06/12/2002 12:58:26 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 816 Lines: 29 >> On Mon, 10 Jun 2002, Mala Anand wrote: >> I have seen this problem with this NIC. You need to increase >> the number of buffers in the RX and TX ring in eepro100.c file. >> Right now it is set to 32, change it to 256 or 128 this error >> will go away. > Donald Becker wrote: >Changing the Tx queue size or number of Rx skbuffs waiting to be filled >will not fix a problem. It might mask some problem e.g. a temporary >shortage of skbuffs, but it doesn't fix anything. The problem what I saw was resource problem and as a result I had packet drops. The input rate was high and the driver didn't have enough resources to handle. It was a pure resource problem. -- Regards, Mala Mala Anand E-mail:manand@us.ibm.com Linux Technology Center - Performance Phone:838-8088; Tie-line:678-8088 From owner-netdev@oss.sgi.com Wed Jun 12 09:58:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5CGwHnC022804 for ; Wed, 12 Jun 2002 09:58:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CGwHIa022803 for netdev-outgoing; Wed, 12 Jun 2002 09:58:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pincoya.inf.utfsm.cl (IDENT:root@pincoya.inf.utfsm.cl [200.1.19.3]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CGw9nC022756 for ; Wed, 12 Jun 2002 09:58:10 -0700 Received: from pincoya.inf.utfsm.cl (IDENT:vonbrand@localhost.inf.utfsm.cl [127.0.0.1]) by pincoya.inf.utfsm.cl (8.12.3/8.12.3) with ESMTP id g5CH0Q7i004389; Wed, 12 Jun 2002 13:00:26 -0400 Received: from pincoya.inf.utfsm.cl (vonbrand@localhost) by pincoya.inf.utfsm.cl (8.12.3/8.12.3) with ESMTP id g5CH0Prd004386; Wed, 12 Jun 2002 13:00:25 -0400 Message-Id: <200206121700.g5CH0Prd004386@pincoya.inf.utfsm.cl> To: Mark Mielke cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: RFC: per-socket statistics on received/dropped packets In-Reply-To: Message from Mark Mielke of "Wed, 12 Jun 2002 10:53:55 -0400." <20020612105355.A20760@mark.mielke.cc> Date: Wed, 12 Jun 2002 13:00:25 -0400 From: Horst von Brand Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2130 Lines: 48 [CC:'s chopped down to the lists] Mark Mielke > On Wed, Jun 12, 2002 at 09:00:08AM -0400, jamal wrote: > > On Wed, 12 Jun 2002, Lincoln Dale wrote: > > > At 08:33 AM 12/06/2002 -0400, jamal wrote: > > > >If 3 people need it, then i would like to ask we add lawn mower > > > >support that my relatives have been asking for the last 5 years. > > > lawn-mower support sounds like a userspace application to me. > > But we need a new system call support > > This is another non-argument not dissimilar to the method of arguing that > David has used up to this point. > > If lawn-mower support (whatever that is) is something that people > would use, then perhaps it *should* be added, even if it needs a new > system call. You have not shown a valid argument against your own > sarcastic suggestion, other than an implicit sneer. Linux development has _always_ worked by: 1) You have a problem 2) You come up with a solution 3) Others use your patch, perhaps refine it 4) A discussion ensues on the worthyness of the patch 5) The community (or at least the halfgods in charge of keeping the Holy Source ;-) sees that the patch is worthwile, tested, and has enough users 6) After some further cleanups and fixes the patch is accepted into the kernel 7) The code is carried as part of the standard kernel, and updated with it Being halfway through (2) or going on (3) and whining that _others_ do the work to take care of finishing implementing a solution and then maintaining it for you (jumping to (7)) won't get you anywehere. Guaranteed. Perhaps your proposed solution is subobtimal. Perhaps your problem is so outlandish that a solution has no place in the standard kernel. Perhaps solving the problem, even a common one, isn't worth the effort in placing a solution in the kernel, and then maintaining it forever. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From owner-netdev@oss.sgi.com Wed Jun 12 10:40:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5CHeWnC026967 for ; Wed, 12 Jun 2002 10:40:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CHeWMp026966 for netdev-outgoing; Wed, 12 Jun 2002 10:40:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CHeRnC026963 for ; Wed, 12 Jun 2002 10:40:28 -0700 Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5CHgoe8016042; Wed, 12 Jun 2002 13:42:50 -0400 Received: from w-nivedita2.des.beaverton.ibm.com (w-nivedita2.des.beaverton.ibm.com [9.47.18.16]) by northrelay01.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5CHgd798398; Wed, 12 Jun 2002 13:42:39 -0400 Date: Wed, 12 Jun 2002 10:42:40 -0700 (PDT) From: Nivedita Singhvi X-X-Sender: To: Mala Anand cc: Donald Becker , , , , Subject: Re: Network oops In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1069 Lines: 30 On Wed, 12 Jun 2002, Mala Anand wrote: > >> On Mon, 10 Jun 2002, Mala Anand wrote: > > >> I have seen this problem with this NIC. You need to increase > >> the number of buffers in the RX and TX ring in eepro100.c file. > >> Right now it is set to 32, change it to 256 or 128 this error > >> will go away. > > > Donald Becker wrote: > >Changing the Tx queue size or number of Rx skbuffs waiting to be filled > >will not fix a problem. It might mask some problem e.g. a temporary > >shortage of skbuffs, but it doesn't fix anything. > > The problem what I saw was resource problem and as a result I had packet > drops. The > input rate was high and the driver didn't have enough resources to handle. > It was a pure resource problem. > -- I think the problem Donald Becker is referring to is the fact that it oopses when out of resources, (or whatever), and that is not a graceful and acceptable thing. Adding resources pushes the problem to a point under additional stress/load/consumption. It would be nice if that were handled gracefully. thanks, Nivedita From owner-netdev@oss.sgi.com Wed Jun 12 11:21:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5CILYnC028190 for ; Wed, 12 Jun 2002 11:21:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CILY2G028189 for netdev-outgoing; Wed, 12 Jun 2002 11:21:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from brinquendo.conectiva.com.br (1-126.ctame701-2.telepar.net.br [200.181.138.126]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CILSnC028185 for ; Wed, 12 Jun 2002 11:21:30 -0700 Received: by brinquendo.conectiva.com.br (Postfix, from userid 500) id CB14F1966C; Wed, 12 Jun 2002 15:23:48 -0300 (BRT) Date: Wed, 12 Jun 2002 15:23:48 -0300 From: Arnaldo Carvalho de Melo To: "David S.Miller" Cc: netdev@oss.sgi.com Subject: [RFC] SNMP_ADD_STATS Message-ID: <20020612182348.GP1073@conectiva.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Url: http://advogato.org/person/acme Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 650 Lines: 26 Hi, I've been cleaning up the network stacks and one thing that made me have a use for the barf bags I have handy is this type of construct: ip_statistics[smp_processor_id()*2 + !in_softirq()].IpFragCreates += nfrags; I've noticed that there is: #define SNMP_INC_STATS(mib, field) ((mib)[2*smp_processor_id()+!in_softirq()].field++) and #define IP_INC_STATS(field) SNMP_INC_STATS(ip_statistics, field) So I propose that we have #define SNMP_ADD_STATS(mib, field, incr) ((mib)[2*smp_processor_id()+!in_softirq()].field += incr) and #define IP_ADD_STATS(field,incr) SNMP_ADD_STATS(ip_statistics, field, incr) Any objections? - Arnaldo From owner-netdev@oss.sgi.com Wed Jun 12 15:46:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5CMkMnC017063 for ; Wed, 12 Jun 2002 15:46:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CMkMWc017062 for netdev-outgoing; Wed, 12 Jun 2002 15:46:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sex.inr.ac.ru (sex.inr.ac.ru [193.233.7.165]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CMkInC017059 for ; Wed, 12 Jun 2002 15:46:19 -0700 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id CAA16949; Thu, 13 Jun 2002 02:47:46 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200206122247.CAA16949@sex.inr.ac.ru> Subject: Re: [RFC] SNMP_ADD_STATS To: acme@conectiva.COM.BR (Arnaldo Carvalho de Melo) Date: Thu, 13 Jun 2002 02:47:46 +0400 (MSD) Cc: netdev@oss.sgi.com In-Reply-To: <20020612182348.GP1073@conectiva.com.br> from "Arnaldo Carvalho de Melo" at Jun 12, 2 10:45:00 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 143 Lines: 9 Hello! > Any objections? No objections, of course. In any case, access to per-cpu stats is to be macroized to work with preemption. Alexey From owner-netdev@oss.sgi.com Wed Jun 12 16:00:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5CN02nC017276 for ; Wed, 12 Jun 2002 16:00:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CN02Bt017275 for netdev-outgoing; Wed, 12 Jun 2002 16:00:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CMxxnC017263 for ; Wed, 12 Jun 2002 16:00:00 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id PAA32485; Wed, 12 Jun 2002 15:58:05 -0700 Date: Wed, 12 Jun 2002 15:58:04 -0700 (PDT) Message-Id: <20020612.155804.36818109.davem@redhat.com> To: acme@conectiva.com.br Cc: netdev@oss.sgi.com Subject: Re: [RFC] SNMP_ADD_STATS From: "David S. Miller" In-Reply-To: <20020612182348.GP1073@conectiva.com.br> References: <20020612182348.GP1073@conectiva.com.br> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 368 Lines: 14 From: Arnaldo Carvalho de Melo Date: Wed, 12 Jun 2002 15:23:48 -0300 So I propose that we have #define SNMP_ADD_STATS(mib, field, incr) ((mib)[2*smp_processor_id()+!in_softirq()].field += incr) and #define IP_ADD_STATS(field,incr) SNMP_ADD_STATS(ip_statistics, field, incr) Any objections? No problem. From owner-netdev@oss.sgi.com Wed Jun 12 16:01:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5CN19nC017377 for ; Wed, 12 Jun 2002 16:01:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CN19su017375 for netdev-outgoing; Wed, 12 Jun 2002 16:01:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from www.linux.org.uk (parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CN10nC017311; Wed, 12 Jun 2002 16:01:00 -0700 Received: from adsl-17-114-120.asm.bellsouth.net ([68.17.114.120] helo=mandrakesoft.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 17IH98-0004BT-00; Thu, 13 Jun 2002 00:03:22 +0100 Message-ID: <3D07D270.5060902@mandrakesoft.com> Date: Wed, 12 Jun 2002 19:00:00 -0400 From: Jeff Garzik Organization: MandrakeSoft User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/00200205 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Zhang Fuxin CC: linux-mips@oss.sgi.com, saw@saw.sw.com.sg, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: NAPI for eepro100 References: <3D0740ED.2060907@ict.ac.cn> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 989 Lines: 30 Zhang Fuxin wrote: > hi,all > Recently i've converted eepro100 driver to use napi,in order to improve > network performance of my poor 150M mips machine. It does eliminate > the interrupt live lock seen before,maintaining a peak throughput under > heavy load. > In case anybody are interested,i post the patches to the list. They are > 3 incremental patchs: > eepro100-napi.patch is against 2.5.20 eepro100.c and provide basic > napi support Nifty, I'll take a look at this. > eepro100-proc.patch is proc file system support adapted from intel's > e100 driver. I am using it for debugging. > eepro100-mips.patch is mips specific patch to make it work(well) for > my mips > platform. Just FWIW I'm not gonna apply these... for the 'proc' patch, that either needs to be moved to ethtool, or we should make a filesystem for net drivers that exports procfs-like inodes. for the 'mips' patch, it looks like the arch maintainer(s) need to fix the PCI DMA support... Jeff From owner-netdev@oss.sgi.com Wed Jun 12 16:07:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5CN7UnC017716 for ; Wed, 12 Jun 2002 16:07:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CN7UL2017715 for netdev-outgoing; Wed, 12 Jun 2002 16:07:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CN7SnC017712; Wed, 12 Jun 2002 16:07:28 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id QAA32547; Wed, 12 Jun 2002 16:05:32 -0700 Date: Wed, 12 Jun 2002 16:05:32 -0700 (PDT) Message-Id: <20020612.160532.134201977.davem@redhat.com> To: jgarzik@mandrakesoft.com Cc: fxzhang@ict.ac.cn, linux-mips@oss.sgi.com, saw@saw.sw.com.sg, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: NAPI for eepro100 From: "David S. Miller" In-Reply-To: <3D07D270.5060902@mandrakesoft.com> References: <3D0740ED.2060907@ict.ac.cn> <3D07D270.5060902@mandrakesoft.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 352 Lines: 12 From: Jeff Garzik Date: Wed, 12 Jun 2002 19:00:00 -0400 for the 'mips' patch, it looks like the arch maintainer(s) need to fix the PCI DMA support... No, it's worse than that. See how non-consistent memory is used by the eepro100 driver for descriptor bits? The skb->tail bits? That is very problematic. From owner-netdev@oss.sgi.com Wed Jun 12 16:18:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5CNIvnC017979 for ; Wed, 12 Jun 2002 16:18:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CNIvMl017978 for netdev-outgoing; Wed, 12 Jun 2002 16:18:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from www.linux.org.uk (parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CNImnC017953; Wed, 12 Jun 2002 16:18:49 -0700 Received: from adsl-17-114-120.asm.bellsouth.net ([68.17.114.120] helo=mandrakesoft.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 17IHQT-0004V8-00; Thu, 13 Jun 2002 00:21:17 +0100 Message-ID: <3D07D6A6.7090308@mandrakesoft.com> Date: Wed, 12 Jun 2002 19:17:58 -0400 From: Jeff Garzik Organization: MandrakeSoft User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/00200205 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: fxzhang@ict.ac.cn, linux-mips@oss.sgi.com, saw@saw.sw.com.sg, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: NAPI for eepro100 References: <3D0740ED.2060907@ict.ac.cn> <3D07D270.5060902@mandrakesoft.com> <20020612.160532.134201977.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 824 Lines: 28 David S. Miller wrote: > From: Jeff Garzik > Date: Wed, 12 Jun 2002 19:00:00 -0400 > > for the 'mips' patch, it looks > like the arch maintainer(s) need to fix the PCI DMA support... > > No, it's worse than that. > > See how non-consistent memory is used by the eepro100 driver > for descriptor bits? The skb->tail bits? > > That is very problematic. Oh crap, you're right... eepro100 in general does funky stuff with the way packets are handled, mainly due to the need to issue commands to the NIC engine instead of the normal per-descriptor owner bit way of doing things. Well, I accept patches to that clean eepro100 up... I'm not terribly motivated to clean it up myself, as we have e100 and an e100 maintainer we can beat on if such uglies arise :) Jeff From owner-netdev@oss.sgi.com Wed Jun 12 16:35:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5CNZfnC018201 for ; Wed, 12 Jun 2002 16:35:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CNZfC8018200 for netdev-outgoing; Wed, 12 Jun 2002 16:35:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CNZdnC018197; Wed, 12 Jun 2002 16:35:39 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id QAA00328; Wed, 12 Jun 2002 16:33:44 -0700 Date: Wed, 12 Jun 2002 16:33:44 -0700 (PDT) Message-Id: <20020612.163344.31410429.davem@redhat.com> To: jgarzik@mandrakesoft.com Cc: fxzhang@ict.ac.cn, linux-mips@oss.sgi.com, saw@saw.sw.com.sg, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: NAPI for eepro100 From: "David S. Miller" In-Reply-To: <3D07D6A6.7090308@mandrakesoft.com> References: <3D07D270.5060902@mandrakesoft.com> <20020612.160532.134201977.davem@redhat.com> <3D07D6A6.7090308@mandrakesoft.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 453 Lines: 10 From: Jeff Garzik Date: Wed, 12 Jun 2002 19:17:58 -0400 Oh crap, you're right... eepro100 in general does funky stuff with the way packets are handled, mainly due to the need to issue commands to the NIC engine instead of the normal per-descriptor owner bit way of doing things. The question is, do the descriptor bits have to live right before the RX packet data buffer or can other schemes be used? From owner-netdev@oss.sgi.com Wed Jun 12 17:09:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5D093nC018843 for ; Wed, 12 Jun 2002 17:09:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5D0937S018842 for netdev-outgoing; Wed, 12 Jun 2002 17:09:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5D091nC018838 for ; Wed, 12 Jun 2002 17:09:01 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 827A914722; Thu, 13 Jun 2002 02:11:25 +0200 (MEST) Date: Thu, 13 Jun 2002 02:11:19 +0200 From: Andi Kleen To: Arnaldo Carvalho de Melo Cc: "David S.Miller" , netdev@oss.sgi.com Subject: Re: [RFC] SNMP_ADD_STATS Message-ID: <20020613021119.A11732@wotan.suse.de> References: <20020612182348.GP1073@conectiva.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020612182348.GP1073@conectiva.com.br> User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 265 Lines: 10 > #define IP_ADD_STATS(field,incr) SNMP_ADD_STATS(ip_statistics, field, incr) > > Any objections? Better use per_cpu data in 2.5 () for the MIBs. That's much more efficient on some architectures, uses less memory on all and is also cleaner. -Andi From owner-netdev@oss.sgi.com Wed Jun 12 19:23:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5D2N9nC019926 for ; Wed, 12 Jun 2002 19:23:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5D2N9Lv019925 for netdev-outgoing; Wed, 12 Jun 2002 19:23:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from localhost.localdomain (dsl093-054-208.blt1.dsl.speakeasy.net [66.93.54.208]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5D2N3nC019922; Wed, 12 Jun 2002 19:23:04 -0700 Received: from localhost (becker@localhost) by localhost.localdomain (8.9.3/8.8.7) with ESMTP id WAA01410; Wed, 12 Jun 2002 22:25:22 -0400 Date: Wed, 12 Jun 2002 22:25:22 -0400 (EDT) From: Donald Becker X-X-Sender: To: "David S. Miller" cc: Jeff Garzik , , Linux Kernel Mailing List , Subject: Re: NAPI for eepro100 In-Reply-To: <20020612.163344.31410429.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1049 Lines: 25 On Wed, 12 Jun 2002, David S. Miller wrote: > From: Jeff Garzik > Oh crap, you're right... eepro100 in general does funky stuff with the > way packets are handled, mainly due to the need to issue commands to the > NIC engine instead of the normal per-descriptor owner bit way of doing > things. The eepro100 has a unique design in many different aspects. > The question is, do the descriptor bits have to live right before > the RX packet data buffer or can other schemes be used? With the current driver structure, yes, the descriptor words must be immediately before the packet data. You can use other Rx and Tx structures/modes to avoid this, but they use less efficient memory access. For instance, the current Tx structure allows transmitting a packet with a single PCI burst, rather than multiple transfers. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From owner-netdev@oss.sgi.com Wed Jun 12 20:57:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5D3vDnC021545 for ; Wed, 12 Jun 2002 20:57:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5D3vDJ6021544 for netdev-outgoing; Wed, 12 Jun 2002 20:57:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from hotmail.com (f228.pav2.hotmail.com [64.4.37.228]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5D3vBnC021541 for ; Wed, 12 Jun 2002 20:57:11 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 12 Jun 2002 20:59:37 -0700 Received: from 166.104.46.15 by pv2fd.pav2.hotmail.msn.com with HTTP; Thu, 13 Jun 2002 03:59:36 GMT X-Originating-IP: [166.104.46.15] From: "Sung-jae. Lee." To: netdev@oss.sgi.com Subject: Masqurading Question... Date: Thu, 13 Jun 2002 12:59:36 +0900 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Jun 2002 03:59:37.0296 (UTC) FILETIME=[BC430500:01C2128E] Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 289 Lines: 10 In masqurading, how to masq server forward packets to their clients in private network??? I want to know its mechanism or technics... Thanks... :-) _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From owner-netdev@oss.sgi.com Thu Jun 13 00:19:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5D7JTnC023798 for ; Thu, 13 Jun 2002 00:19:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5D7JTQ9023797 for netdev-outgoing; Thu, 13 Jun 2002 00:19:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from shell.webmaster.com (mail.webmaster.com [216.152.64.131]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5D7JQnC023794 for ; Thu, 13 Jun 2002 00:19:26 -0700 Received: from whenever ([206.171.168.130]) by shell.webmaster.com (Post.Office MTA v3.5.3 release 223 ID# 0-12345L500S10000V35) with SMTP id com; Thu, 13 Jun 2002 00:21:55 -0700 From: David Schwartz To: , Horst von Brand , "David S. Miller" CC: Ben Greear , , X-Mailer: PocoMail 2.61 (1025) - Licensed Version Date: Thu, 13 Jun 2002 00:21:54 -0700 In-Reply-To: <5.1.0.14.2.20020612221925.0283fb18@mira-sjcm-3.cisco.com> Subject: Re: RFC: per-socket statistics on received/dropped packets Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <20020613072155.AAA14363@shell.webmaster.com@whenever> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g5D7JQnC023795 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 252 Lines: 12 >i know of many many folk who use transaction logs from HTTP caches for >volume-based billing. >right now, those bills are anywhere between 10% to 25% incorrect. You are being paid to deliver packets to their destination, not to drop them. DS From owner-netdev@oss.sgi.com Thu Jun 13 01:44:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5D8i5nC025064 for ; Thu, 13 Jun 2002 01:44:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5D8i51S025063 for netdev-outgoing; Thu, 13 Jun 2002 01:44:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5D8hxnC025060 for ; Thu, 13 Jun 2002 01:43:59 -0700 Received: from mira-sjcm-3.cisco.com (IDENT:mirapoint@mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5D8k4PI001864; Thu, 13 Jun 2002 01:46:04 -0700 (PDT) Received: from ltd-t22.cisco.com (syd-vpn-client-194-6.cisco.com [10.64.194.6]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id AFD89147; Thu, 13 Jun 2002 01:47:13 -0700 (PDT) Message-Id: <5.1.0.14.2.20020613183120.03222cb8@mira-sjcm-3.cisco.com> X-Sender: ltd@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 13 Jun 2002 18:44:20 +1000 To: David Schwartz From: Lincoln Dale Subject: Re: RFC: per-socket statistics on received/dropped packets Cc: Horst von Brand , "David S. Miller" , Ben Greear , , , jamal In-Reply-To: <20020613072155.AAA14363@shell.webmaster.com@whenever> References: <5.1.0.14.2.20020612221925.0283fb18@mira-sjcm-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1879 Lines: 47 > >i know of many many folk who use transaction logs from HTTP caches for > >volume-based billing. > >right now, those bills are anywhere between 10% to 25% incorrect. > > You are being paid to deliver packets to their destination, not > to drop >them. ho hum. yes, that is typically true of a transit provider. however, the transit provider wants to charge the customer not just for what is delivered to layer-7, but also for packetization overhead at layer-2/layer-3/layer-4. after all, the IP+TCP packet headers are delivered to the client as well, no? this is just my point: there is NO method to account for those pesky headers! also, think of the case where a HTTP Proxy _isn't_ in the path of traffic. from this side of the Pacific, if there are TCP retransmissions, they are end-to-end retransmissions, across that really expensive piece of wet string otherwise known as an undersea cable. _that_ is the most expensive hop and if a customer is congested on the last mile, they're still eating into the expensive bandwidth! discussions on the layer-8 (religion) or layer-9 (politics) aspects of whether it is correct to bill based on that is irrelevant. what is relevant is that there isn't any mechanism to count the overhead of packetization or the overhead of using a "reliable stream transport" such as TCP. i do have the code to do this. its relatively trivial and consumes an extra 8 bytes of RAM per socket. it doesn't obfuscate the existing kernel code nor does it slow the code down by any tangible amount. it is a compile-time option so for those people who don't know or care about it, it doesn't impact them at all. yet, clearly, Dave and Jamal are vehemently opposed to it. alas, that means it stays as an out-of-kernel patch and will likely continue to suffer bit-rot as time goes by. c'est la vie. cheers, lincoln. From owner-netdev@oss.sgi.com Thu Jun 13 01:45:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5D8jtnC025170 for ; Thu, 13 Jun 2002 01:45:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5D8jskR025169 for netdev-outgoing; Thu, 13 Jun 2002 01:45:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from castle.nmd.msu.ru (castle.nmd.msu.ru [193.232.112.53]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5D8jonC025154 for ; Thu, 13 Jun 2002 01:45:51 -0700 Received: (qmail 23773 invoked by uid 577); 13 Jun 2002 08:57:53 -0000 Message-ID: <20020613125753.A23693@castle.nmd.msu.ru> Date: Thu, 13 Jun 2002 12:57:53 +0400 From: Andrey Savochkin To: "David S. Miller" Cc: fxzhang@ict.ac.cn, linux-mips@oss.sgi.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jgarzik@mandrakesoft.com Subject: Re: NAPI for eepro100 References: <3D0740ED.2060907@ict.ac.cn> <3D07D270.5060902@mandrakesoft.com> <20020612.160532.134201977.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <20020612.160532.134201977.davem@redhat.com>; from "David S. Miller" on Wed, Jun 12, 2002 at 04:05:32PM Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 558 Lines: 19 On Wed, Jun 12, 2002 at 04:05:32PM -0700, David S. Miller wrote: > From: Jeff Garzik > Date: Wed, 12 Jun 2002 19:00:00 -0400 > > for the 'mips' patch, it looks > like the arch maintainer(s) need to fix the PCI DMA support... > > No, it's worse than that. > > See how non-consistent memory is used by the eepro100 driver > for descriptor bits? The skb->tail bits? > > That is very problematic. What's the problem? If it isn't allowed to do, then what is the meaning of PCI_DMA_BIDIRECTIONAL mappings? Andrey From owner-netdev@oss.sgi.com Thu Jun 13 01:49:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5D8n1nC025367 for ; Thu, 13 Jun 2002 01:49:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5D8n1Ir025366 for netdev-outgoing; Thu, 13 Jun 2002 01:49:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5D8mvnC025363; Thu, 13 Jun 2002 01:48:57 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id BAA03164; Thu, 13 Jun 2002 01:47:00 -0700 Date: Thu, 13 Jun 2002 01:47:00 -0700 (PDT) Message-Id: <20020613.014700.26430433.davem@redhat.com> To: saw@saw.sw.com.sg Cc: fxzhang@ict.ac.cn, linux-mips@oss.sgi.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jgarzik@mandrakesoft.com Subject: Re: NAPI for eepro100 From: "David S. Miller" In-Reply-To: <20020613125753.A23693@castle.nmd.msu.ru> References: <3D07D270.5060902@mandrakesoft.com> <20020612.160532.134201977.davem@redhat.com> <20020613125753.A23693@castle.nmd.msu.ru> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 796 Lines: 22 From: Andrey Savochkin Date: Thu, 13 Jun 2002 12:57:53 +0400 On Wed, Jun 12, 2002 at 04:05:32PM -0700, David S. Miller wrote: > No, it's worse than that. > > See how non-consistent memory is used by the eepro100 driver > for descriptor bits? The skb->tail bits? > > That is very problematic. What's the problem? If it isn't allowed to do, then what is the meaning of PCI_DMA_BIDIRECTIONAL mappings? It's slow. Not wrong, just inefficient. Descriptors were meant to be done using consistent mappings, not "pci_map_*()"'d memory. The latter is meant to be used for long linear DMA transfers to/from the device. It is not meant for things the cpu pokes small bits of data in and out of, that is what consistent DMA memory is for. From owner-netdev@oss.sgi.com Thu Jun 13 03:08:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5DA8FnC026577 for ; Thu, 13 Jun 2002 03:08:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5DA8F5g026576 for netdev-outgoing; Thu, 13 Jun 2002 03:08:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from shell.webmaster.com (mail.webmaster.com [216.152.64.131]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5DA86nC026572 for ; Thu, 13 Jun 2002 03:08:06 -0700 Received: from whenever ([206.171.168.130]) by shell.webmaster.com (Post.Office MTA v3.5.3 release 223 ID# 0-12345L500S10000V35) with SMTP id com; Thu, 13 Jun 2002 03:10:36 -0700 From: David Schwartz To: CC: Horst von Brand , "David S. Miller" , Ben Greear , , , jamal X-Mailer: PocoMail 2.61 (1025) - Licensed Version Date: Thu, 13 Jun 2002 03:10:35 -0700 In-Reply-To: <5.1.0.14.2.20020613183120.03222cb8@mira-sjcm-3.cisco.com> Subject: Re: RFC: per-socket statistics on received/dropped packets Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <20020613101036.AAA25884@shell.webmaster.com@whenever> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g5DA87nC026573 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 3029 Lines: 68 On Thu, 13 Jun 2002 18:44:20 +1000, Lincoln Dale wrote: >>You are being paid to deliver packets to their destination, not >>to drop >>them. >ho hum. >yes, that is typically true of a transit provider. >however, the transit provider wants to charge the customer not just for >what is delivered to layer-7, but also for packetization overhead at >layer-2/layer-3/layer-4. after all, the IP+TCP packet headers are >delivered to the client as well, no? Actually, the customer really only cares about payload. And if the overhead is a constant ratio to the data, just adjust the rate and it all comes out in the wash. The only reason to care is if you want to play games, such as saying you charge the same rate 'per byte' as another provider when you really don't. >this is just my point: there is NO method to account for those pesky >headers! No is there any need to. Do you really need to differentially account for customers who have more 'overhead bytes per data byte' than others? Or can you just say it's 12% and raise/lower your rates 12% >also, think of the case where a HTTP Proxy _isn't_ in the path of >traffic. from this side of the Pacific, if there are TCP retransmissions, >they are end-to-end retransmissions, across that really expensive piece of >wet string otherwise known as an undersea cable. _that_ is the most >expensive hop and if a customer is congested on the last mile, they're >still eating into the expensive bandwidth! But accounting for the retransmissions won't help you, because you can't tell retransmissions that the customer should rightly pay for versus retransmissions that he shouldn't. So again, you can't do any better than to just work it into the base price. >discussions on the layer-8 (religion) or layer-9 (politics) aspects of >whether it is correct to bill based on that is irrelevant. what is >relevant is that there isn't any mechanism to count the overhead of >packetization or the overhead of using a "reliable stream transport" such >as TCP. I realize that, but I don't see what good it is. So yes, it's something that's currently hard to do, but if there's no legitimate need, then it doesn't matter whether it's hard or not. You pose problems and you pose a solution, but unless you can show that the solution actually solves the problem, the solution is of no value. >i do have the code to do this. its relatively trivial and consumes an >extra 8 bytes of RAM per socket. >it doesn't obfuscate the existing kernel code nor does it slow the code >down by any tangible amount. >it is a compile-time option so for those people who don't know or care >about it, it doesn't impact them at all. >yet, clearly, Dave and Jamal are vehemently opposed to it. >alas, that means it stays as an out-of-kernel patch and will likely >continue to suffer bit-rot as time goes by. c'est la vie. Well, show them a real-world problem that it solves. Show a case where you can't bill fairly without it and you can bill fairly with it. ... If you can. DS From owner-netdev@oss.sgi.com Thu Jun 13 05:40:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5DCeKnC008126 for ; Thu, 13 Jun 2002 05:40:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5DCeKB3008125 for netdev-outgoing; Thu, 13 Jun 2002 05:40:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5DCeEnC008121 for ; Thu, 13 Jun 2002 05:40:14 -0700 Received: from mail7.nc.rr.com (mail7.southeast.rr.com [24.93.67.54]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id FAA05061 for ; Thu, 13 Jun 2002 05:42:57 -0700 (PDT) mail_from (cfriesen@nortelnetworks.com) Received: from mail pickup service by mail7.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 08:17:33 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 15:34:42 -0400 Received: from vger.kernel.org (vger.kernel.org [209.116.70.75]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AJYfIc012124 for ; Mon, 10 Jun 2002 15:34:41 -0400 (EDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 10 Jun 2002 15:28:30 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 10 Jun 2002 15:28:29 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]:24708 "EHLO zcars04f.ca.nortel.com") by vger.kernel.org with ESMTP id ; Mon, 10 Jun 2002 15:28:27 -0400 Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5AJSED11644; Mon, 10 Jun 2002 15:28:15 -0400 (EDT) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KTYBR6AX; Mon, 10 Jun 2002 15:28:14 -0400 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MSYXG6SA; Mon, 10 Jun 2002 15:28:15 -0400 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 4DCED540E; Mon, 10 Jun 2002 15:28:14 -0400 (EDT) Message-ID: <3D04FDCE.110096E2@nortelnetworks.com> Date: Mon, 10 Jun 2002 15:28:14 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Chris Friesen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-kernel@vger.kernel.org Cc: netdev@oss.sgi.com Subject: Re: RFC: per-socket statistics on received/dropped packets References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: linux-kernel@vger.kernel.org Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1972 Lines: 43 jamal wrote: > > On Mon, 10 Jun 2002, Mark Mielke wrote: > > There *are* applications that would benefit from making this decision > > at run time on a socket-by-socket basis. It is not a common requirement > > for most desktop users, but it remains a valid requirement. > > > > I am confused as to which application needs this, do you have one in mind? > AFAIK, UDP/RTP type apps already know how to determine packet loss > on a per flow basis. The purpose of this patch is to make it reallly easy to nail down exactly how many packets were dropped *per socket*, and for what reason. For me, the information is then used to tune the application statically, but others could use it dynamically. Incoming packets can be dropped at the device, at the device driver, in netif_rx, or at the socket buffer. We've got stats on all of these except for the socket buffer, so why not add them? The cost in the normal case is incrementing a single variable in the socket struct (which is likely already in cache since we're playing with it). I can't see this being that expensive. In the failure path, we get a second increment. Again, this is not going to be noticeable. Sure, you can try and figure out which applications had sockets open, and how many packets they missed, and subtract that from the snmp counters to give how many packets you missed. But to do this you have to lock the box down--isn't it a lot easier to just *know* because you've been keeping track? Chris -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From owner-netdev@oss.sgi.com Fri Jun 14 03:35:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5EAZInC002157 for ; Fri, 14 Jun 2002 03:35:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5EAZIVb002156 for netdev-outgoing; Fri, 14 Jun 2002 03:35:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5EAZBnC002152 for ; Fri, 14 Jun 2002 03:35:12 -0700 Received: from corsair.sgi.com (corsair.sgi.com [192.26.67.33]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id FAA66831 for ; Fri, 14 Jun 2002 05:37:41 -0500 (CDT) Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by corsair.sgi.com (8.12.3/8.12.3/linux-nospam-1.4) with ESMTP id g5EAbfI4025434 for ; Fri, 14 Jun 2002 03:37:41 -0700 Received: from mail pickup service by mail8.nc.rr.com with Microsoft SMTPSVC; Fri, 14 Jun 2002 02:39:51 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 15:34:41 -0400 Received: from vger.kernel.org (vger.kernel.org [209.116.70.75]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AJYfIa012124 for ; Mon, 10 Jun 2002 15:34:41 -0400 (EDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 10 Jun 2002 15:28:30 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 10 Jun 2002 15:28:29 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]:24708 "EHLO zcars04f.ca.nortel.com") by vger.kernel.org with ESMTP id ; Mon, 10 Jun 2002 15:28:27 -0400 Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5AJSED11644; Mon, 10 Jun 2002 15:28:15 -0400 (EDT) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KTYBR6AX; Mon, 10 Jun 2002 15:28:14 -0400 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MSYXG6SA; Mon, 10 Jun 2002 15:28:15 -0400 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 4DCED540E; Mon, 10 Jun 2002 15:28:14 -0400 (EDT) Message-ID: <3D04FDCE.110096E2@nortelnetworks.com> Date: Mon, 10 Jun 2002 15:28:14 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Chris Friesen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-kernel@vger.kernel.org Cc: netdev@oss.sgi.com Subject: Re: RFC: per-socket statistics on received/dropped packets References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: linux-kernel@vger.kernel.org Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1972 Lines: 43 jamal wrote: > > On Mon, 10 Jun 2002, Mark Mielke wrote: > > There *are* applications that would benefit from making this decision > > at run time on a socket-by-socket basis. It is not a common requirement > > for most desktop users, but it remains a valid requirement. > > > > I am confused as to which application needs this, do you have one in mind? > AFAIK, UDP/RTP type apps already know how to determine packet loss > on a per flow basis. The purpose of this patch is to make it reallly easy to nail down exactly how many packets were dropped *per socket*, and for what reason. For me, the information is then used to tune the application statically, but others could use it dynamically. Incoming packets can be dropped at the device, at the device driver, in netif_rx, or at the socket buffer. We've got stats on all of these except for the socket buffer, so why not add them? The cost in the normal case is incrementing a single variable in the socket struct (which is likely already in cache since we're playing with it). I can't see this being that expensive. In the failure path, we get a second increment. Again, this is not going to be noticeable. Sure, you can try and figure out which applications had sockets open, and how many packets they missed, and subtract that from the snmp counters to give how many packets you missed. But to do this you have to lock the box down--isn't it a lot easier to just *know* because you've been keeping track? Chris -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From owner-netdev@oss.sgi.com Fri Jun 14 03:35:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5EAZOnC002168 for ; Fri, 14 Jun 2002 03:35:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5EAZOPq002167 for netdev-outgoing; Fri, 14 Jun 2002 03:35:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5EAZInC002155 for ; Fri, 14 Jun 2002 03:35:18 -0700 Received: from corsair.sgi.com (corsair.sgi.com [192.26.67.33]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id FAA76237 for ; Fri, 14 Jun 2002 05:37:49 -0500 (CDT) Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by corsair.sgi.com (8.12.3/8.12.3/linux-nospam-1.4) with ESMTP id g5EAbmI4025463 for ; Fri, 14 Jun 2002 03:37:49 -0700 Received: from mail pickup service by mail8.nc.rr.com with Microsoft SMTPSVC; Fri, 14 Jun 2002 02:39:57 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 15:34:41 -0400 Received: from vger.kernel.org (vger.kernel.org [209.116.70.75]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AJYfIb012124 for ; Mon, 10 Jun 2002 15:34:41 -0400 (EDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 10 Jun 2002 15:28:30 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 10 Jun 2002 15:28:29 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]:24708 "EHLO zcars04f.ca.nortel.com") by vger.kernel.org with ESMTP id ; Mon, 10 Jun 2002 15:28:27 -0400 Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5AJSED11644; Mon, 10 Jun 2002 15:28:15 -0400 (EDT) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KTYBR6AX; Mon, 10 Jun 2002 15:28:14 -0400 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MSYXG6SA; Mon, 10 Jun 2002 15:28:15 -0400 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 4DCED540E; Mon, 10 Jun 2002 15:28:14 -0400 (EDT) Message-ID: <3D04FDCE.110096E2@nortelnetworks.com> Date: Mon, 10 Jun 2002 15:28:14 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Chris Friesen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-kernel@vger.kernel.org Cc: netdev@oss.sgi.com Subject: Re: RFC: per-socket statistics on received/dropped packets References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: linux-kernel@vger.kernel.org Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1972 Lines: 43 jamal wrote: > > On Mon, 10 Jun 2002, Mark Mielke wrote: > > There *are* applications that would benefit from making this decision > > at run time on a socket-by-socket basis. It is not a common requirement > > for most desktop users, but it remains a valid requirement. > > > > I am confused as to which application needs this, do you have one in mind? > AFAIK, UDP/RTP type apps already know how to determine packet loss > on a per flow basis. The purpose of this patch is to make it reallly easy to nail down exactly how many packets were dropped *per socket*, and for what reason. For me, the information is then used to tune the application statically, but others could use it dynamically. Incoming packets can be dropped at the device, at the device driver, in netif_rx, or at the socket buffer. We've got stats on all of these except for the socket buffer, so why not add them? The cost in the normal case is incrementing a single variable in the socket struct (which is likely already in cache since we're playing with it). I can't see this being that expensive. In the failure path, we get a second increment. Again, this is not going to be noticeable. Sure, you can try and figure out which applications had sockets open, and how many packets they missed, and subtract that from the snmp counters to give how many packets you missed. But to do this you have to lock the box down--isn't it a lot easier to just *know* because you've been keeping track? Chris -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From owner-netdev@oss.sgi.com Fri Jun 14 03:36:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5EAaEnC002202 for ; Fri, 14 Jun 2002 03:36:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5EAaEsn002201 for netdev-outgoing; Fri, 14 Jun 2002 03:36:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5EAa7nC002197 for ; Fri, 14 Jun 2002 03:36:08 -0700 Received: from corsair.sgi.com (corsair.sgi.com [192.26.67.33]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id FAA64490 for ; Fri, 14 Jun 2002 05:38:37 -0500 (CDT) Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by corsair.sgi.com (8.12.3/8.12.3/linux-nospam-1.4) with ESMTP id g5EAcbI4025682 for ; Fri, 14 Jun 2002 03:38:37 -0700 Received: from mail pickup service by mail8.nc.rr.com with Microsoft SMTPSVC; Fri, 14 Jun 2002 02:40:16 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 15:34:41 -0400 Received: from vger.kernel.org (vger.kernel.org [209.116.70.75]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AJYfId012124 for ; Mon, 10 Jun 2002 15:34:42 -0400 (EDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 10 Jun 2002 15:28:30 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 10 Jun 2002 15:28:29 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]:24708 "EHLO zcars04f.ca.nortel.com") by vger.kernel.org with ESMTP id ; Mon, 10 Jun 2002 15:28:27 -0400 Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5AJSED11644; Mon, 10 Jun 2002 15:28:15 -0400 (EDT) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KTYBR6AX; Mon, 10 Jun 2002 15:28:14 -0400 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MSYXG6SA; Mon, 10 Jun 2002 15:28:15 -0400 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 4DCED540E; Mon, 10 Jun 2002 15:28:14 -0400 (EDT) Message-ID: <3D04FDCE.110096E2@nortelnetworks.com> Date: Mon, 10 Jun 2002 15:28:14 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Chris Friesen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-kernel@vger.kernel.org Cc: netdev@oss.sgi.com Subject: Re: RFC: per-socket statistics on received/dropped packets References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: linux-kernel@vger.kernel.org Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1972 Lines: 43 jamal wrote: > > On Mon, 10 Jun 2002, Mark Mielke wrote: > > There *are* applications that would benefit from making this decision > > at run time on a socket-by-socket basis. It is not a common requirement > > for most desktop users, but it remains a valid requirement. > > > > I am confused as to which application needs this, do you have one in mind? > AFAIK, UDP/RTP type apps already know how to determine packet loss > on a per flow basis. The purpose of this patch is to make it reallly easy to nail down exactly how many packets were dropped *per socket*, and for what reason. For me, the information is then used to tune the application statically, but others could use it dynamically. Incoming packets can be dropped at the device, at the device driver, in netif_rx, or at the socket buffer. We've got stats on all of these except for the socket buffer, so why not add them? The cost in the normal case is incrementing a single variable in the socket struct (which is likely already in cache since we're playing with it). I can't see this being that expensive. In the failure path, we get a second increment. Again, this is not going to be noticeable. Sure, you can try and figure out which applications had sockets open, and how many packets they missed, and subtract that from the snmp counters to give how many packets you missed. But to do this you have to lock the box down--isn't it a lot easier to just *know* because you've been keeping track? Chris -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From owner-netdev@oss.sgi.com Fri Jun 14 11:07:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5EI7wnC022004 for ; Fri, 14 Jun 2002 11:07:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5EI7vta022003 for netdev-outgoing; Fri, 14 Jun 2002 11:07:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from grok.yi.org (IDENT:kveEZnnX8vhdfZ/Xbol3WIXS77oK8X31@ip68-3-14-32.ph.ph.cox.net [68.3.14.32]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5EI7rnC022000 for ; Fri, 14 Jun 2002 11:07:53 -0700 Received: from candelatech.com (IDENT:lBw83Z4ThKKbTX4B84mWtDyHQyuByq8L@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.2) with ESMTP id g5EI9pL23995; Fri, 14 Jun 2002 11:09:51 -0700 Message-ID: <3D0A316F.6010701@candelatech.com> Date: Fri, 14 Jun 2002 11:09:51 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Stephen Hemminger CC: Lincoln Dale , jamal , Horst von Brand , "David S. Miller" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: RFC: per-socket statistics on received/dropped packets References: <5.1.0.14.2.20020612224038.0251bd08@mira-sjcm-3.cisco.com> <5.1.0.14.2.20020614100914.01adca48@mira-sjcm-3.cisco.com> <1024069878.20676.1.camel@dell_ss3.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 859 Lines: 29 Stephen Hemminger wrote: > It sounds like what you want is socket accounting which works like > process accounting. I.e when a socket lifetime ends, put out a record > with number of packets/bytes sent/received. Runtime is much more interesting to me. However, if you are keeping enough information to do the accounting as you suggest, then it would be trivial to make it available incrementally over the life of the socket. Billing is not the only interesting aspect of this. It is also good for any program trying to dynamically tune or understand the lower-level characteristics of a particular routing path or interface. Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From owner-netdev@oss.sgi.com Fri Jun 14 15:32:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5EMWUnC026307 for ; Fri, 14 Jun 2002 15:32:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5EMWUH8026306 for netdev-outgoing; Fri, 14 Jun 2002 15:32:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5EMWKnC026296 for ; Fri, 14 Jun 2002 15:32:20 -0700 Received: from saturn.blackbox.com ([209.119.238.78]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id PAA06529 for ; Fri, 14 Jun 2002 15:34:57 -0700 (PDT) mail_from (NAVMSE-SATURN@BlackBox.com) Received: by saturn.blackbox.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 18:33:34 -0400 Message-ID: <5ABB259D7DCE4443A8F1063A5636CCC2E35CC2@saturn.blackbox.com> From: NAV for Microsoft Exchange-SATURN To: "'netdev'" Subject: Norton AntiVirus detected a virus in a message you sent. The inf ected attachment was deleted. Date: Fri, 14 Jun 2002 18:33:33 -0400 X-MS-TNEF-Correlator: <5ABB259D7DCE4443A8F1063A5636CCC2E35CC2@saturn.blackbox.com> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C213F3.8424A550" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 4139 Lines: 69 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C213F3.8424A550 Content-Type: text/plain Recipient of the infected attachment: Info\Inbox Subject of the message: A special funny game One or more attachments were deleted Attachment picacu.exe was Deleted for the following reasons: Virus W32.Klez.H@mm was found. **************************************************************************** **** This email and any files transmitted with it are confidential and are intended for the sole use of the individual to whom they are addressed. Black Box Corporation reserves the right to scan all e-mail traffic for restricted content and to monitor all e-mail in general. If you are not the intended recipient or you have received this email in error, any use, dissemination or forwarding of this email is strictly prohibited. If you have received this email in error, please notify the sender by replying to this email. ------_=_NextPart_000_01C213F3.8424A550 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IiMWAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAA0gcGAA4AEgAhACEABQBGAQEggAMADgAAANIHBgAO ABIAIQAhAAUARgEBCYABACEAAAAyODhGRjA0NjU4QTZERDQwQjg3NDA1NTVGODI1OTlEQwAqBwEE gAEAXwAAAE5vcnRvbiBBbnRpVmlydXMgZGV0ZWN0ZWQgYSB2aXJ1cyBpbiBhIG1lc3NhZ2UgeW91 IHNlbnQuICBUaGUgaW5mZWN0ZWQgYXR0YWNobWVudCB3YXMgZGVsZXRlZC4AHyIBDYAEAAIAAAAC AAIAAQOQBgBYBwAAIAAAAAIBCRABAAAAvwIAALsCAABPBAAATFpGde7a3BqHAAoBDQNDdGV4dAH3 /wKkA+QF6wKDAFAC8wa0AoMmMgPFAgBjaArAc2XYdDAgBxMCgzMS3xPm/n0KgAjPCdkCgAqECzcS wj8B0AfwBZAFIAiQAjAgb0BmIHRoZSALgGZjBZAO8GQgYQJAANBoQweAAjA6ICBJGsBvbFxcHBAG 4HgKogqAUzh1Ymoa4Ro2B4FzYYRnZRvhQSBzcBmxAwdAG/BmdW5ueSDMZ2EHgBzET24akAWx7wRg FxAbOQQgdwSQGpABAG5sE7AJgAqiCh6RG1cgZRngYwDQdS4PABqQd/phBCBEIkQfUAWxGnICEMZs FqAD8G5nIBcQJIA5AiBzOhzEG/Ab8FZpBHJ1BCBXMzIuS4EiUHouSEBtbSRj8wIQH3BkLhzEGE0U khlx+QqnICorvyzPLd8u7y+pyQqjVGgEACBlAMADETcAcBshH5FmAxAHkXRy+QBxbWkCQBsRA/Aa cBqg3wVACsAakAWgGsBpAQACMP8fEjGzIPELgA7wKSAlCSaAHSJQICegIIEaVmRpdqU0UHUfIXRv IdBoA3DHGmIfoDPSYWRkFxAEEJEJgC4gQgtgY2s50GUcoCAIUHJwBbAbQGnnAiAmQROgcnYyYhqB BRD8Z2gFQDghBPADkQdAAyD8ZS0xYzKRASAj0CUjOWH/MpAj0BsCNBE1gTOxMcE4If8EYAMAOCAF wDz5C4AfsAnw1wSQB0A5wEkaUHkIYDPD/G5vPFEagzWFFxAZxwXA70IiE3A7kEOiZTegGxEacM8x J0ExBJADYHIsMeM2we9G0DeQOYEy4G465AWxJTF/JHALICYSGkNFyAQgPoRs7R+gcANgMRBiMvA5 okH1/0TPRd8jsCJQJIBCgwaQH6B3NjM1kgXAYh+gFxALUHkvJhI4IUz4KUV9UeAAAwD9P+QEAABA ADkAUKUkhPMTwgEDAPE/CQQAAB4AMUABAAAADgAAAE5BVk1TRS1TQVRVUk4AAAADABpAAAAAAB4A MEABAAAADgAAAE5BVk1TRS1TQVRVUk4AAAADABlAAAAAAB4AcAABAAAAXwAAAE5vcnRvbiBBbnRp VmlydXMgZGV0ZWN0ZWQgYSB2aXJ1cyBpbiBhIG1lc3NhZ2UgeW91IHNlbnQuICBUaGUgaW5mZWN0 ZWQgYXR0YWNobWVudCB3YXMgZGVsZXRlZC4AAAIBcQABAAAAFgAAAAHCE/OEJJxzGW5xb03ljZq2 IzCz+N0AAAsA8hABAAAAAgFHAAEAAAA2AAAAYz1VUzthPSA7cD1CbGFjayBCb3ggQ29ycDtsPVNB VFVSTi0wMjA2MTQyMjMzMzNaLTI3NTMAAAACAfk/AQAAAF4AAAAAAAAA3KdAyMBCEBq0uQgAKy/h ggEAAAAAAAAAL089QkxBQ0sgQk9YIENPUlAvT1U9QkxBQ0tCT1ggLSBIUS9DTj1SRUNJUElFTlRT L0NOPU5BVk1TRS1TQVRVUk4AAAAeAPg/AQAAACIAAABOQVYgZm9yIE1pY3Jvc29mdCBFeGNoYW5n ZS1TQVRVUk4AAAAeADhAAQAAAA4AAABOQVZNU0UtU0FUVVJOAAAAAgH7PwEAAABeAAAAAAAAANyn QMjAQhAatLkIACsv4YIBAAAAAAAAAC9PPUJMQUNLIEJPWCBDT1JQL09VPUJMQUNLQk9YIC0gSFEv Q049UkVDSVBJRU5UUy9DTj1OQVZNU0UtU0FUVVJOAAAAHgD6PwEAAAAiAAAATkFWIGZvciBNaWNy b3NvZnQgRXhjaGFuZ2UtU0FUVVJOAAAAHgA5QAEAAAAOAAAATkFWTVNFLVNBVFVSTgAAAEAABzCc USKE8xPCAUAACDCqeCmE8xPCAR4APQABAAAAAQAAAAAAAAAeAB0OAQAAAF8AAABOb3J0b24gQW50 aVZpcnVzIGRldGVjdGVkIGEgdmlydXMgaW4gYSBtZXNzYWdlIHlvdSBzZW50LiAgVGhlIGluZmVj dGVkIGF0dGFjaG1lbnQgd2FzIGRlbGV0ZWQuAAAeADUQAQAAAD0AAAA8NUFCQjI1OUQ3RENFNDQ0 M0E4RjEwNjNBNTYzNkNDQzJFMzVDQzJAc2F0dXJuLmJsYWNrYm94LmNvbT4AAAAAAwA2AAAAAAAL ACkAAAAAAAsAIwAAAAAAAwAGEC2ir28DAAcQtQIAAAMAEBAAAAAAAwAREAEAAAAeAAgQAQAAAGUA AABSRUNJUElFTlRPRlRIRUlORkVDVEVEQVRUQUNITUVOVDpJTkZPSU5CT1hTVUJKRUNUT0ZUSEVN RVNTQUdFOkFTUEVDSUFMRlVOTllHQU1FT05FT1JNT1JFQVRUQUNITUVOVFNXAAAAAAIBfwABAAAA PQAAADw1QUJCMjU5RDdEQ0U0NDQzQThGMTA2M0E1NjM2Q0NDMkUzNUNDMkBzYXR1cm4uYmxhY2ti b3guY29tPgAAAACc/g== ------_=_NextPart_000_01C213F3.8424A550-- From owner-netdev@oss.sgi.com Fri Jun 14 15:32:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5EMWWnC026314 for ; Fri, 14 Jun 2002 15:32:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5EMWVd3026313 for netdev-outgoing; Fri, 14 Jun 2002 15:32:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5EMWJnC026293 for ; Fri, 14 Jun 2002 15:32:19 -0700 Received: from saturn.blackbox.com ([209.119.238.78]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id PAA09219 for ; Fri, 14 Jun 2002 15:34:53 -0700 (PDT) mail_from (NAVMSE-SATURN@BlackBox.com) Received: by saturn.blackbox.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 18:33:34 -0400 Message-ID: <5ABB259D7DCE4443A8F1063A5636CCC2E35CC4@saturn.blackbox.com> From: NAV for Microsoft Exchange-SATURN To: "'netdev'" Subject: Norton AntiVirus detected a virus in a message you sent. The inf ected attachment was deleted. Date: Fri, 14 Jun 2002 18:33:33 -0400 X-MS-TNEF-Correlator: <5ABB259D7DCE4443A8F1063A5636CCC2E35CC4@saturn.blackbox.com> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C213F3.8432FD30" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 4159 Lines: 69 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C213F3.8432FD30 Content-Type: text/plain Recipient of the infected attachment: test two\Inbox Subject of the message: A special funny game One or more attachments were deleted Attachment picacu.exe was Deleted for the following reasons: Virus W32.Klez.H@mm was found. **************************************************************************** **** This email and any files transmitted with it are confidential and are intended for the sole use of the individual to whom they are addressed. Black Box Corporation reserves the right to scan all e-mail traffic for restricted content and to monitor all e-mail in general. If you are not the intended recipient or you have received this email in error, any use, dissemination or forwarding of this email is strictly prohibited. If you have received this email in error, please notify the sender by replying to this email. ------_=_NextPart_000_01C213F3.8432FD30 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IiMWAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAA0gcGAA4AEgAhACEABQBGAQEggAMADgAAANIHBgAO ABIAIQAhAAUARgEBCYABACEAAAA5NTYyMUVGNTVEMUQxRTREQTdCMTM3OUNEOUNERTA3MwBXBwEE gAEAXwAAAE5vcnRvbiBBbnRpVmlydXMgZGV0ZWN0ZWQgYSB2aXJ1cyBpbiBhIG1lc3NhZ2UgeW91 IHNlbnQuICBUaGUgaW5mZWN0ZWQgYXR0YWNobWVudCB3YXMgZGVsZXRlZC4AHyIBDYAEAAIAAAAC AAIAAQOQBgBkBwAAIQAAAAIBCRABAAAAxAIAAMACAABTBAAATFpGdVRhr/iHAAoBDQNDdGV4dAH3 /wKkA+QF6wKDAFAC8wa0AoMmMgPFAgBjaArAc2XYdDAgBxMCgzMS3xPm/n0KgAjPCdkCgAqECzcS wj8B0AfwBZAFIAiQAjAgb0BmIHRoZSALgGZjBZAO8GQgYQJAANBocweAAjA6IBpgB5AFQHRAd29c XEluBuB4wwqiCoBTdWJqGuEaNiEHgXNhZ2Ub4UEgHHNwGbEHQBvwZnVuYG55IGdhB4AdBE9+bhqQ BbEEYBcQGzkEIHd3BJAakAEAbBOwCYAKogorHtEbVyAZ4GMA0HUu0w8AGpB3YQQgRCKEH5A3BbEa cgIQbBagA/BuZ84gFxAkwAIgczodBBvwIRvwVmlydQQgVzMIMi5LIpB6LkhAnG1tJKMCEB+wZC4d BM8YTRSSGXEKpyAqK/8tD08uHy8vL+kKo1RoBAAgvmUAwAMRAHAbIR/RZgMQyQeRdHIAcW1pAkAb Ef8D8BpwGqAFQArAGpAFoBrA/mkBAAIwH1Ix8yExC4AO8O8pYCVJJsAikCAn4CDBGlYoZGl2NJB1 H2F0bz0iEGgDcBpiH+A0EmFkjmQXEAQQCYAuIEILYCxjazoQHOAgCFBycDsFsBtAaQIgJoEToHJ2 5zKiGoEFEGdoHEE4cATw5wORB0ADIGUtMaMy0QEg/yQQJWM5oTLQJBAbAjRRNcH/M/EyAThhBGAD ADhgBcA9Ob8LgB/wCfAEkAdAOgBJGlDmeQhgNANubxxBGoM1xX8XEBnHBcBCYhNwO9BD4mV/N+Ab ERpwMWdBcQSQA2ByfiwyIzcBRxA30DnBMyBu/zskBbElcSSwCyAmUhpDRghrBCA+xGwf4HADYDFQ Yv8zMDniQjVFD0YfI/AikCTAv0LDBpAf4DZzNdIFwGIf4HsXEAtQeSZSOGFNOCmFfQFSIAMA/T/k BAAAQAA5ADD9MoTzE8IBAwDxPwkEAAAeADFAAQAAAA4AAABOQVZNU0UtU0FUVVJOAAAAAwAaQAAA AAAeADBAAQAAAA4AAABOQVZNU0UtU0FUVVJOAAAAAwAZQAAAAAACAXEAAQAAABYAAAABwhPzhDPy hGt+ysZDH74UlSuMVwQOAAADACYAAAAAAAMANgAAAAAAHgBwAAEAAABfAAAATm9ydG9uIEFudGlW aXJ1cyBkZXRlY3RlZCBhIHZpcnVzIGluIGEgbWVzc2FnZSB5b3Ugc2VudC4gIFRoZSBpbmZlY3Rl ZCBhdHRhY2htZW50IHdhcyBkZWxldGVkLgAACwDyEAEAAAACAUcAAQAAADYAAABjPVVTO2E9IDtw PUJsYWNrIEJveCBDb3JwO2w9U0FUVVJOLTAyMDYxNDIyMzMzM1otMjc1NQAAAAIB+T8BAAAAXgAA AAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAvTz1CTEFDSyBCT1ggQ09SUC9PVT1CTEFDS0JP WCAtIEhRL0NOPVJFQ0lQSUVOVFMvQ049TkFWTVNFLVNBVFVSTgAAAB4A+D8BAAAAIgAAAE5BViBm b3IgTWljcm9zb2Z0IEV4Y2hhbmdlLVNBVFVSTgAAAB4AOEABAAAADgAAAE5BVk1TRS1TQVRVUk4A AAACAfs/AQAAAF4AAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089QkxBQ0sgQk9YIENP UlAvT1U9QkxBQ0tCT1ggLSBIUS9DTj1SRUNJUElFTlRTL0NOPU5BVk1TRS1TQVRVUk4AAAAeAPo/ AQAAACIAAABOQVYgZm9yIE1pY3Jvc29mdCBFeGNoYW5nZS1TQVRVUk4AAAAeADlAAQAAAA4AAABO QVZNU0UtU0FUVVJOAAAAQAAHMLifMITzE8IBQAAIMCApOoTzE8IBHgA9AAEAAAABAAAAAAAAAB4A HQ4BAAAAXwAAAE5vcnRvbiBBbnRpVmlydXMgZGV0ZWN0ZWQgYSB2aXJ1cyBpbiBhIG1lc3NhZ2Ug eW91IHNlbnQuICBUaGUgaW5mZWN0ZWQgYXR0YWNobWVudCB3YXMgZGVsZXRlZC4AAB4ANRABAAAA PQAAADw1QUJCMjU5RDdEQ0U0NDQzQThGMTA2M0E1NjM2Q0NDMkUzNUNDNEBzYXR1cm4uYmxhY2ti b3guY29tPgAAAAALACkAAAAAAAsAIwAAAAAAAwAGEBWZhdADAAcQuAIAAAMAEBAAAAAAAwAREAEA AAAeAAgQAQAAAGUAAABSRUNJUElFTlRPRlRIRUlORkVDVEVEQVRUQUNITUVOVDpURVNUVFdPSU5C T1hTVUJKRUNUT0ZUSEVNRVNTQUdFOkFTUEVDSUFMRlVOTllHQU1FT05FT1JNT1JFQVRUQUNITUVO AAAAAAIBfwABAAAAPQAAADw1QUJCMjU5RDdEQ0U0NDQzQThGMTA2M0E1NjM2Q0NDMkUzNUNDNEBz YXR1cm4uYmxhY2tib3guY29tPgAAAACc9Q== ------_=_NextPart_000_01C213F3.8432FD30-- From owner-netdev@oss.sgi.com Fri Jun 14 17:11:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5F0BFnC027841 for ; Fri, 14 Jun 2002 17:11:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5F0BF6e027840 for netdev-outgoing; Fri, 14 Jun 2002 17:11:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from dea.linux-mips.net (c-180-196-6.ka.dial.de.ignite.net [62.180.196.6]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5F0BBnC027833 for ; Fri, 14 Jun 2002 17:11:12 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5F0C0Z22477 for netdev@oss.sgi.com; Sat, 15 Jun 2002 02:12:00 +0200 Received: from mail.tiscalinet.it (mail-8.tiscalinet.it [195.130.225.154]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5EF8WnC009819 for ; Fri, 14 Jun 2002 08:08:33 -0700 Received: from luigicart (62.11.18.10) by mail.tiscalinet.it (5.5.057) id 3D0476100026D4F4 for netdev@oss.sgi.com; Fri, 14 Jun 2002 13:12:16 +0200 Message-ID: <007301c21394$d102bba0$0a120b3e@luigicart> From: "Luigi Cartuccia" To: Subject: frag problem Date: Fri, 14 Jun 2002 13:15:39 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0070_01C213A5.93F47BC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2312 Lines: 62 This is a multi-part message in MIME format. ------=_NextPart_000_0070_01C213A5.93F47BC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Good morning I'm Luigi Cartuccia an italian student.I have a = fragmentation problem.I have installed a software for routing multi-hop = for wireless Lan 802.11.I use linux-2.4.7. My problem: Without the software ssh and scp is ok With the software ssh is ok and scp is not ok Instead the writer of the software have used linux-2.4.3 and with the = software,he have asked me,scp is ok. I have discovered that it is a fragmentation's problem in fact the = fragment.c file is various for linux-2.4.3 and linux-2.4.7. Can you help me? Thank you very much=20 Luigi ------=_NextPart_000_0070_01C213A5.93F47BC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Good morning I'm Luigi Cartuccia an = italian=20 student.I have a fragmentation problem.I have installed a software for = routing=20 multi-hop for wireless Lan 802.11.I use linux-2.4.7.
My problem:
Without the software ssh and scp is = ok
With the software ssh is ok and scp is = not=20 ok
Instead the writer of the software have = used=20 linux-2.4.3 and with the software,he have asked me,scp is = ok.
I have discovered that it is a = fragmentation's=20 problem in fact the fragment.c file is various for linux-2.4.3 and=20 linux-2.4.7.
Can you help me?
Thank you very much
Luigi
 
------=_NextPart_000_0070_01C213A5.93F47BC0-- From owner-netdev@oss.sgi.com Fri Jun 14 17:11:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5F0BfnC027887 for ; Fri, 14 Jun 2002 17:11:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5F0Bf2E027886 for netdev-outgoing; Fri, 14 Jun 2002 17:11:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from dea.linux-mips.net (c-180-196-6.ka.dial.de.ignite.net [62.180.196.6]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5F0BHnC027847 for ; Fri, 14 Jun 2002 17:11:18 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5F0C6v22483 for netdev@oss.sgi.com; Sat, 15 Jun 2002 02:12:06 +0200 Received: from mail.osdl.org (air-2.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5EFnunC010184 for ; Fri, 14 Jun 2002 08:49:56 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id g5EFpWR26203; Fri, 14 Jun 2002 08:51:32 -0700 Subject: Re: RFC: per-socket statistics on received/dropped packets From: Stephen Hemminger To: Lincoln Dale Cc: jamal , Horst von Brand , "David S. Miller" , Ben Greear , linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <5.1.0.14.2.20020614100914.01adca48@mira-sjcm-3.cisco.com> References: <5.1.0.14.2.20020612224038.0251bd08@mira-sjcm-3.cisco.com> <5.1.0.14.2.20020614100914.01adca48@mira-sjcm-3.cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 14 Jun 2002 08:51:15 -0700 Message-Id: <1024069878.20676.1.camel@dell_ss3.pdx.osdl.net> Mime-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 3857 Lines: 87 It sounds like what you want is socket accounting which works like process accounting. I.e when a socket lifetime ends, put out a record with number of packets/bytes sent/received. On Thu, 2002-06-13 at 17:24, Lincoln Dale wrote: > At 09:00 AM 12/06/2002 -0400, jamal wrote: > > > > > i know of many many folk who use transaction logs from HTTP caches for > > > > > volume-based billing. > > > > > right now, those bills are anywhere between 10% to 25% incorrect. > > > > > > > > > > you call that "extremely limited"? > > > > > > > >Surely, you must have better ways to do accounting than this -- otherwise > > > >you deserve to loose money. > > > > > > many people don't have better ways to do accounting than this. > > > >Then they dont care about loosing money. > >There's nothing _more important_ to a service provider than ability to do > >proper billing. Otherwise, they are a charity organization. > > on this side of the planet (Australia), just about *all* service-providers > offer differentiated-billing baed on a volume-usage basis. > that includes Worldcom, Telstra, Optus (SingTel), connect.com.au (AAPT). > some of these differentiate themselves by using caching to provide faster > access and/or mitigate the latency overhead of simplex satellite. > this has been ongoing for many many many years now. please just accept > that HTTP caching is almost a necessity with the pricing models in use! > > >There's nothing _more important_ to a service provider than ability to do > >proper billing. Otherwise, they are a charity organization. > > we're almost talking about the same thing here -- and this is my point! i > agree that is is important - hence why i've added a getsockopt() option to > provide octet counters from the ip+tcp level! > > > > in the case of Squid and Linux, they're typically using it because its > > > open-source and "free". > > > >I am hoping you didnt mean to say squid was only good because it has > >these perks. > > not at all. they're using it because it meets their requirements. > once again, this is not a discussion about religion or politics! > > > > they want to use HTTP Caching to save bandwidth (and therefore save money), > > > but they also live in a regime of volume-based billing. (not everywhere on > > > the planet is fixed-$/month for DSL). > > > > > > the unfortunate solution is to use HTTP Transaction logs, which count > > > payload at layer-7, not payload+headers+retransmissions at layer-3. > > > >Look at your own employers eqpt if you want to do this right. > >And then search around freshmeat so you dont reinvent the wheel. > > once again, i respectfully disagree. while there are numerous technologies > for accounting out there (e.g. netflow), they all break down when you have > things like HTTP Persistent connections which may share a single > [server-side] connection with multiple [client-side] connections. > > >And until you prove it is worth it and useful to other people then > >forever thats where it belongs. I now of nobody serious about billing > >who is using sockets stats as the transaction point. > > you live in a country where the billing regeme is different. > > > > lawn-mower support sounds like a userspace application to me. > > > >But we need a new system call support > > (yes, i did take that comment as humerous before :-)). > > if what i was proposing involved a new system-call then i agree that there > would be signficant pushback. what i have is a new getsockopt() > option. ie. in reality, no worse than getsockopt(..,TCP_INFO). > > > cheers, > > lincoln. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ From owner-netdev@oss.sgi.com Fri Jun 14 17:12:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5F0CNnC027922 for ; Fri, 14 Jun 2002 17:12:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5F0CNl4027921 for netdev-outgoing; Fri, 14 Jun 2002 17:12:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from dea.linux-mips.net (c-180-196-6.ka.dial.de.ignite.net [62.180.196.6]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5F0CFnC027916 for ; Fri, 14 Jun 2002 17:12:16 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5F0D4W22501 for netdev@oss.sgi.com; Sat, 15 Jun 2002 02:13:04 +0200 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CCiMnC014524 for ; Wed, 12 Jun 2002 05:44:22 -0700 Received: from mira-sjcm-3.cisco.com (IDENT:mirapoint@mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g5CCkPIZ027502; Wed, 12 Jun 2002 05:46:25 -0700 (PDT) Received: from ltd-t22.cisco.com (syd-vpn-client-194-31.cisco.com [10.64.194.31]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id AFD61317; Wed, 12 Jun 2002 05:47:33 -0700 (PDT) Message-Id: <5.1.0.14.2.20020612224038.0251bd08@mira-sjcm-3.cisco.com> X-Sender: ltd@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 12 Jun 2002 22:44:44 +1000 To: jamal From: Lincoln Dale Subject: Re: RFC: per-socket statistics on received/dropped packets Cc: Horst von Brand , "David S. Miller" , Ben Greear , , In-Reply-To: References: <5.1.0.14.2.20020612221925.0283fb18@mira-sjcm-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1557 Lines: 42 At 08:33 AM 12/06/2002 -0400, jamal wrote: > > i know of many many folk who use transaction logs from HTTP caches for > > volume-based billing. > > right now, those bills are anywhere between 10% to 25% incorrect. > > > > you call that "extremely limited"? > >Surely, you must have better ways to do accounting than this -- otherwise >you deserve to loose money. many people don't have better ways to do accounting than this. in the case of Squid and Linux, they're typically using it because its open-source and "free". they want to use HTTP Caching to save bandwidth (and therefore save money), but they also live in a regime of volume-based billing. (not everywhere on the planet is fixed-$/month for DSL). the unfortunate solution is to use HTTP Transaction logs, which count payload at layer-7, not payload+headers+retransmissions at layer-3. > > of course, i am doing exactly what Dave said to do -- maintaining my own > > out-of-kernel patch -- but its a pain, i'm sure it will soon conflict with > > stuff and is a damn shame - it isn't much code, but Dave seems pretty > > steadfast that he isn't interested. > >You havent proven why its needed. And from the looks of it you dont even >need it. i don't need it because i already have it in my kernel. but thats where it ends -- its destined to forever be a private patch. >If 3 people need it, then i would like to ask we add lawn mower >support that my relatives have been asking for the last 5 years. lawn-mower support sounds like a userspace application to me. cheers, lincoln. From owner-netdev@oss.sgi.com Fri Jun 14 17:12:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5F0CrnC027995 for ; Fri, 14 Jun 2002 17:12:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5F0CrC7027994 for netdev-outgoing; Fri, 14 Jun 2002 17:12:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from dea.linux-mips.net (c-180-196-6.ka.dial.de.ignite.net [62.180.196.6]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5F0CnnC027991 for ; Fri, 14 Jun 2002 17:12:51 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5F0DcK22519 for netdev@oss.sgi.com; Sat, 15 Jun 2002 02:13:38 +0200 Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CD3UnC014692 for ; Wed, 12 Jun 2002 06:03:31 -0700 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id JAA03103; Wed, 12 Jun 2002 09:05:57 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g5CD08800930; Wed, 12 Jun 2002 09:00:08 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Wed, 12 Jun 2002 09:00:08 -0400 (EDT) From: jamal To: Lincoln Dale cc: Horst von Brand , "David S. Miller" , Ben Greear , , Subject: Re: RFC: per-socket statistics on received/dropped packets In-Reply-To: <5.1.0.14.2.20020612224038.0251bd08@mira-sjcm-3.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 2281 Lines: 65 On Wed, 12 Jun 2002, Lincoln Dale wrote: > At 08:33 AM 12/06/2002 -0400, jamal wrote: > > > i know of many many folk who use transaction logs from HTTP caches for > > > volume-based billing. > > > right now, those bills are anywhere between 10% to 25% incorrect. > > > > > > you call that "extremely limited"? > > > >Surely, you must have better ways to do accounting than this -- otherwise > >you deserve to loose money. > > many people don't have better ways to do accounting than this. > Then they dont care about loosing money. There's nothing _more important_ to a service provider than ability to do proper billing. Otherwise, they are a charity organization. > in the case of Squid and Linux, they're typically using it because its > open-source and "free". I am hoping you didnt mean to say squid was only good because it has these perks. > > they want to use HTTP Caching to save bandwidth (and therefore save money), > but they also live in a regime of volume-based billing. (not everywhere on > the planet is fixed-$/month for DSL). > > the unfortunate solution is to use HTTP Transaction logs, which count > payload at layer-7, not payload+headers+retransmissions at layer-3. > Look at your own employers eqpt if you want to do this right. And then search around freshmeat so you dont reinvent the wheel. > > > of course, i am doing exactly what Dave said to do -- maintaining my own > > > out-of-kernel patch -- but its a pain, i'm sure it will soon conflict with > > > stuff and is a damn shame - it isn't much code, but Dave seems pretty > > > steadfast that he isn't interested. > > > >You havent proven why its needed. And from the looks of it you dont even > >need it. > > i don't need it because i already have it in my kernel. > but thats where it ends -- its destined to forever be a private patch. > And until you prove it is worth it and useful to other people then forever thats where it belongs. I now of nobody serious about billing who is using sockets stats as the transaction point. > >If 3 people need it, then i would like to ask we add lawn mower > >support that my relatives have been asking for the last 5 years. > > lawn-mower support sounds like a userspace application to me. > But we need a new system call support cheers, jamal From owner-netdev@oss.sgi.com Fri Jun 14 17:13:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5F0DGnC028120 for ; Fri, 14 Jun 2002 17:13:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5F0DGZP028118 for netdev-outgoing; Fri, 14 Jun 2002 17:13:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from dea.linux-mips.net (c-180-196-6.ka.dial.de.ignite.net [62.180.196.6]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5F0D3nC028034 for ; Fri, 14 Jun 2002 17:13:04 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5F0DqE22527 for netdev@oss.sgi.com; Sat, 15 Jun 2002 02:13:52 +0200 Received: from ivexgw1.intruvert.com (mx1.intruvert.com [65.209.235.20]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CKSJnC029685 for ; Wed, 12 Jun 2002 13:28:19 -0700 Received: by ivexgw.intruvert.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 13:30:43 -0700 Message-ID: From: Yan-Fa Li To: "'Ben Greear'" , Pekka Savola Cc: Mark Mielke , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: RE: RFC: per-socket statistics on received/dropped packets Date: Wed, 12 Jun 2002 13:30:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21250.003397A0" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1824 Lines: 52 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21250.003397A0 Content-Type: text/plain Does this do what is needed ? I've used it and it does have an impact on stack performance while the application is running, but it tells you about retransmits and what not, and does not seem to affect performance much until you actually want to inspect the values. I agree with DaveM that it should not go into the mainline kernel unless you can turn it off with a sysctl, but it is useful for debugging and network health monitoring. Y http://heron.ucsd.edu/tcphealth/ ------_=_NextPart_001_01C21250.003397A0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: RFC: per-socket statistics on received/dropped = packets

Does this do what is needed ?  I've used it and = it does have an impact on stack performance while the application is = running, but it tells you about retransmits and what not, and does not = seem to affect  performance much until you actually want to = inspect the values.  I agree with DaveM that it should not go into = the mainline kernel unless you can turn it off with a sysctl, but it is = useful for debugging and network health monitoring.

Y

http://heron.ucsd.edu/tcphealth/

------_=_NextPart_001_01C21250.003397A0-- From owner-netdev@oss.sgi.com Fri Jun 14 17:13:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5F0DGnC028119 for ; Fri, 14 Jun 2002 17:13:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5F0DGAS028117 for netdev-outgoing; Fri, 14 Jun 2002 17:13:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from dea.linux-mips.net (c-180-196-6.ka.dial.de.ignite.net [62.180.196.6]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5F0DAnC028072 for ; Fri, 14 Jun 2002 17:13:12 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5F0Dxo22531 for netdev@oss.sgi.com; Sat, 15 Jun 2002 02:13:59 +0200 Received: from ivexgw1.intruvert.com (mx1.intruvert.com [65.209.235.20]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CKSJnC029685 for ; Wed, 12 Jun 2002 13:28:19 -0700 Received: by ivexgw.intruvert.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 13:30:43 -0700 Message-ID: From: Yan-Fa Li To: "'Ben Greear'" , Pekka Savola Cc: Mark Mielke , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: RE: RFC: per-socket statistics on received/dropped packets Date: Wed, 12 Jun 2002 13:30:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21250.003397A0" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1824 Lines: 52 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21250.003397A0 Content-Type: text/plain Does this do what is needed ? I've used it and it does have an impact on stack performance while the application is running, but it tells you about retransmits and what not, and does not seem to affect performance much until you actually want to inspect the values. I agree with DaveM that it should not go into the mainline kernel unless you can turn it off with a sysctl, but it is useful for debugging and network health monitoring. Y http://heron.ucsd.edu/tcphealth/ ------_=_NextPart_001_01C21250.003397A0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: RFC: per-socket statistics on received/dropped = packets

Does this do what is needed ?  I've used it and = it does have an impact on stack performance while the application is = running, but it tells you about retransmits and what not, and does not = seem to affect  performance much until you actually want to = inspect the values.  I agree with DaveM that it should not go into = the mainline kernel unless you can turn it off with a sysctl, but it is = useful for debugging and network health monitoring.

Y

http://heron.ucsd.edu/tcphealth/

------_=_NextPart_001_01C21250.003397A0-- From owner-netdev@oss.sgi.com Fri Jun 14 17:13:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5F0DMnC028182 for ; Fri, 14 Jun 2002 17:13:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5F0DMU8028181 for netdev-outgoing; Fri, 14 Jun 2002 17:13:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from dea.linux-mips.net (c-180-196-6.ka.dial.de.ignite.net [62.180.196.6]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5F0DInC028138 for ; Fri, 14 Jun 2002 17:13:20 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5F0E7a22537 for netdev@oss.sgi.com; Sat, 15 Jun 2002 02:14:07 +0200 Received: from mail7.nc.rr.com (mail7.southeast.rr.com [24.93.67.54]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5D1JOnC019439 for ; Wed, 12 Jun 2002 18:19:25 -0700 Received: from mail pickup service by mail7.nc.rr.com with Microsoft SMTPSVC; Wed, 12 Jun 2002 19:49:48 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 12 Jun 2002 08:49:18 -0400 Received: from vger.kernel.org (vger.kernel.org [209.116.70.75]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5CCnIbE025016 for ; Wed, 12 Jun 2002 08:49:18 -0400 (EDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 12 Jun 2002 08:47:02 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 12 Jun 2002 08:47:01 -0400 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]:50933 "EHLO sj-msg-core-4.cisco.com") by vger.kernel.org with ESMTP id ; Wed, 12 Jun 2002 08:47:00 -0400 Received: from mira-sjcm-3.cisco.com (IDENT:mirapoint@mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g5CCkPIZ027502; Wed, 12 Jun 2002 05:46:25 -0700 (PDT) Received: from ltd-t22.cisco.com (syd-vpn-client-194-31.cisco.com [10.64.194.31]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id AFD61317; Wed, 12 Jun 2002 05:47:33 -0700 (PDT) Message-Id: <5.1.0.14.2.20020612224038.0251bd08@mira-sjcm-3.cisco.com> X-Sender: ltd@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 12 Jun 2002 22:44:44 +1000 To: jamal From: Lincoln Dale Subject: Re: RFC: per-socket statistics on received/dropped packets Cc: Horst von Brand , "David S. Miller" , Ben Greear , , In-Reply-To: References: <5.1.0.14.2.20020612221925.0283fb18@mira-sjcm-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: linux-kernel@vger.kernel.org Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1802 Lines: 48 At 08:33 AM 12/06/2002 -0400, jamal wrote: > > i know of many many folk who use transaction logs from HTTP caches for > > volume-based billing. > > right now, those bills are anywhere between 10% to 25% incorrect. > > > > you call that "extremely limited"? > >Surely, you must have better ways to do accounting than this -- otherwise >you deserve to loose money. many people don't have better ways to do accounting than this. in the case of Squid and Linux, they're typically using it because its open-source and "free". they want to use HTTP Caching to save bandwidth (and therefore save money), but they also live in a regime of volume-based billing. (not everywhere on the planet is fixed-$/month for DSL). the unfortunate solution is to use HTTP Transaction logs, which count payload at layer-7, not payload+headers+retransmissions at layer-3. > > of course, i am doing exactly what Dave said to do -- maintaining my own > > out-of-kernel patch -- but its a pain, i'm sure it will soon conflict with > > stuff and is a damn shame - it isn't much code, but Dave seems pretty > > steadfast that he isn't interested. > >You havent proven why its needed. And from the looks of it you dont even >need it. i don't need it because i already have it in my kernel. but thats where it ends -- its destined to forever be a private patch. >If 3 people need it, then i would like to ask we add lawn mower >support that my relatives have been asking for the last 5 years. lawn-mower support sounds like a userspace application to me. cheers, lincoln. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From owner-netdev@oss.sgi.com Fri Jun 14 17:13:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5F0DunC028385 for ; Fri, 14 Jun 2002 17:13:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5F0DuXd028384 for netdev-outgoing; Fri, 14 Jun 2002 17:13:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from dea.linux-mips.net (c-180-196-6.ka.dial.de.ignite.net [62.180.196.6]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5F0DpnC028338 for ; Fri, 14 Jun 2002 17:13:53 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5F0EeA22547 for netdev@oss.sgi.com; Sat, 15 Jun 2002 02:14:41 +0200 Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5DAXwnC005523 for ; Thu, 13 Jun 2002 03:33:59 -0700 Received: from mail pickup service by mail5.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 06:34:38 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Wed, 12 Jun 2002 08:49:18 -0400 Received: from vger.kernel.org (vger.kernel.org [209.116.70.75]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5CCnIbD025016 for ; Wed, 12 Jun 2002 08:49:18 -0400 (EDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 12 Jun 2002 08:47:02 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 12 Jun 2002 08:47:01 -0400 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]:50933 "EHLO sj-msg-core-4.cisco.com") by vger.kernel.org with ESMTP id ; Wed, 12 Jun 2002 08:47:00 -0400 Received: from mira-sjcm-3.cisco.com (IDENT:mirapoint@mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g5CCkPIZ027502; Wed, 12 Jun 2002 05:46:25 -0700 (PDT) Received: from ltd-t22.cisco.com (syd-vpn-client-194-31.cisco.com [10.64.194.31]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id AFD61317; Wed, 12 Jun 2002 05:47:33 -0700 (PDT) Message-Id: <5.1.0.14.2.20020612224038.0251bd08@mira-sjcm-3.cisco.com> X-Sender: ltd@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 12 Jun 2002 22:44:44 +1000 To: jamal From: Lincoln Dale Subject: Re: RFC: per-socket statistics on received/dropped packets Cc: Horst von Brand , "David S. Miller" , Ben Greear , , In-Reply-To: References: <5.1.0.14.2.20020612221925.0283fb18@mira-sjcm-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: linux-kernel@vger.kernel.org Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1802 Lines: 48 At 08:33 AM 12/06/2002 -0400, jamal wrote: > > i know of many many folk who use transaction logs from HTTP caches for > > volume-based billing. > > right now, those bills are anywhere between 10% to 25% incorrect. > > > > you call that "extremely limited"? > >Surely, you must have better ways to do accounting than this -- otherwise >you deserve to loose money. many people don't have better ways to do accounting than this. in the case of Squid and Linux, they're typically using it because its open-source and "free". they want to use HTTP Caching to save bandwidth (and therefore save money), but they also live in a regime of volume-based billing. (not everywhere on the planet is fixed-$/month for DSL). the unfortunate solution is to use HTTP Transaction logs, which count payload at layer-7, not payload+headers+retransmissions at layer-3. > > of course, i am doing exactly what Dave said to do -- maintaining my own > > out-of-kernel patch -- but its a pain, i'm sure it will soon conflict with > > stuff and is a damn shame - it isn't much code, but Dave seems pretty > > steadfast that he isn't interested. > >You havent proven why its needed. And from the looks of it you dont even >need it. i don't need it because i already have it in my kernel. but thats where it ends -- its destined to forever be a private patch. >If 3 people need it, then i would like to ask we add lawn mower >support that my relatives have been asking for the last 5 years. lawn-mower support sounds like a userspace application to me. cheers, lincoln. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From owner-netdev@oss.sgi.com Sat Jun 15 13:35:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5FKZtnC009700 for ; Sat, 15 Jun 2002 13:35:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5FKZttW009699 for netdev-outgoing; Sat, 15 Jun 2002 13:35:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from cob427.dn.net ([216.167.37.170]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5FKZpnC009694 for ; Sat, 15 Jun 2002 13:35:52 -0700 Received: from radical.corewars.org ([202.88.151.58]) by cob427.dn.net (8.9.3/8.9.3) with ESMTP id PAA18860 for ; Sat, 15 Jun 2002 15:02:49 +0530 Date: Sat, 15 Jun 2002 14:24:48 +0530 (IST) From: Ankit Jain To: Subject: some queries Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 510 Lines: 17 Hi, I have been trying to find answers to some queries but noone seems to be able to help. My queries are: (kernel 2.4.18) 1. what is tcp_ehash_bucket used for? hash table for tcp sockets? what does the "e" is the ehash mean/represent? 2. Why is a tcp control socket created at init time in tcp_v4_init(..) ? Its of SOCK_RAW type and its unhashed to make sure that it doesnt receive any incoming packets. why? is it used to set some options or something? Where is it used? Hoping for a reply!! :) -Ankit From owner-netdev@oss.sgi.com Sun Jun 16 15:32:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5GMWFnC003274 for ; Sun, 16 Jun 2002 15:32:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5GMWFfC003273 for netdev-outgoing; Sun, 16 Jun 2002 15:32:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from www.linux.org.uk (parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5GMWAnC003270 for ; Sun, 16 Jun 2002 15:32:11 -0700 Received: from adsl-17-114-120.asm.bellsouth.net ([68.17.114.120] helo=mandrakesoft.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 17Jibo-0001KP-00; Sun, 16 Jun 2002 23:34:56 +0100 Message-ID: <3D0D11AA.7070406@mandrakesoft.com> Date: Sun, 16 Jun 2002 18:31:06 -0400 From: Jeff Garzik Organization: MandrakeSoft User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/00200205 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: FreeBSD attempts NAPI... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 666 Lines: 17 [snip from release notes] Selected network drivers now implement a semi-polling mode, which makes systems much more resilient to attacks and overloads. To enable polling, the following options are required in a kernel configuration file: options DEVICE_POLLING options HZ=1000 # not compulsory but strongly recommended The kern.polling.enable sysctl variable will then activate polling mode; with the kern.polling.user_frac sysctl indicating the percentage of CPU time to be reserved for userland. The devices initially supporting polling are dc(4), fxp(4), rl(4), and sis(4). More details can be found in the polling(4) manual page. [end snip] From owner-netdev@oss.sgi.com Mon Jun 17 03:45:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5HAj5nC014907 for ; Mon, 17 Jun 2002 03:45:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5HAj5iG014906 for netdev-outgoing; Mon, 17 Jun 2002 03:45:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from smtp1.us4.outblaze.com (205-158-62-78.outblaze.com [205.158.62.78]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5HAj0nC014901 for ; Mon, 17 Jun 2002 03:45:00 -0700 Received: (qmail 17982 invoked from network); 17 Jun 2002 10:47:44 -0000 Received: from unknown (HELO mail.com) (129.33.49.201) by 205-158-62-78.outblaze.com with SMTP; 17 Jun 2002 10:47:44 -0000 Message-ID: <3D0E6EDF.9010207@mail.com> Date: Mon, 17 Jun 2002 16:21:03 -0700 From: Sridhar Samudrala User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ankit Jain CC: netdev@oss.sgi.com Subject: Re: some queries References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 743 Lines: 36 Ankit Jain wrote: >Hi, > >I have been trying to find answers to some queries but noone seems to be >able to help. My queries are: (kernel 2.4.18) > >1. what is tcp_ehash_bucket used for? hash table for tcp sockets? what >does the "e" is the ehash mean/represent? > It is a hash table of all tcp sockets in ESTABLISHED state. > >2. Why is a tcp control socket created at init time in tcp_v4_init(..) ? >Its of SOCK_RAW type and its unhashed to make sure that it doesnt receive >any incoming packets. why? is it used to set some options or something? >Where is it used? > The main purpose of this socket is to send RSTs when a packet is received for a non-existing socket. Thanks Sridhar > >Hoping for a reply!! :) > >-Ankit > > > > > From owner-netdev@oss.sgi.com Mon Jun 17 13:24:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5HKO4nC029918 for ; Mon, 17 Jun 2002 13:24:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5HKO4au029917 for netdev-outgoing; Mon, 17 Jun 2002 13:24:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from lain.perlfu.co.uk (IDENT:root@pc1-camb4-0-cust108.cam.cable.ntl.com [62.253.133.108]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5HKNdnC029911 for ; Mon, 17 Jun 2002 13:23:41 -0700 Received: from lain.perlfu.co.uk ([192.168.1.10] ident=critson) by lain.perlfu.co.uk with esmtp (Exim 3.34 #5) id 17K34x-0000yk-00; Mon, 17 Jun 2002 21:26:23 +0100 Date: Mon, 17 Jun 2002 21:26:23 +0100 (BST) From: Carl Ritson To: "David S. Miller" cc: Linus Torvalds , Linux Kernel Mailing List , Subject: [PATCH][2.5.22] OOPS in tcp_v6_get_port Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463809535-1287385206-1024317093=:2496" Content-ID: Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 8596 Lines: 180 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1463809535-1287385206-1024317093=:2496 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Sorry for the repeat email but this bug is also in 2.5.22 and my patch is still valid, although I'm not entirely sure it is the correct fix for the problem? -- From Previous email -- 2.5.21 and 2.5.22 OOPS at boot on my test machine, the decoded OOPS is attached. Also attached is a program that triggers the bug, it emulates the behavior of bind on my test machine and binds to two ports one IPv4 and one IPv6 with the same port number but different IP addresses. The bug appears to be the IPv6 TCP code, in net/ipv6/tcp_ipv6.c Line 149: struct ipv6_pinfo *np2 = inet6_sk(sk2); if (sk != sk2 && sk->bound_dev_if == sk2->bound_dev_if) { if (!sk_reuse || !sk2->reuse || sk2->state == TCP_LISTEN) { /* NOTE: IPv6 tw bucket have different format */ if (!inet_sk(sk2)->rcv_saddr || addr_type == IPV6_ADDR_ANY || !ipv6_addr_cmp(&np->rcv_saddr, sk2->state != TCP_TIME_WAIT ? BUG --> &np2->rcv_saddr : &((struct tcp_tw_bucket*)sk)->v6_rcv_saddr) || (addr_type==IPV6_ADDR_MAPPED && sk2->family==AF_INET && inet_sk(sk)->rcv_saddr == inet_sk(sk2)->rcv_saddr)) break; } } } np2 can be NULL if the socket is an IPv4 socket, since IPv6 and IPv4 share the port address space. While the test of !inet_sk(sk2-)->rcv_addr _should_ prevent this it is not assured in C that the conditions to an if statement will be evaluated in the order written? At least my gcc (2.95.4 from compiled from CVS) doesn't think so :-). I propose a diff similar to the one below to fix the problem maybe? Many thanks, Carl Ritson critson@perlfu.co.uk --- orig/net/ipv6/tcp_ipv6.c Sat Jun 15 19:23:44 2002 +++ linux/net/ipv6/tcp_ipv6.c Sat Jun 15 19:21:46 2002 @@ -156,14 +156,16 @@ /* NOTE: IPv6 tw bucket have different format */ if (!inet_sk(sk2)->rcv_saddr || addr_type == IPV6_ADDR_ANY || - !ipv6_addr_cmp(&np->rcv_saddr, - sk2->state != TCP_TIME_WAIT ? - &np2->rcv_saddr : - &((struct tcp_tw_bucket*)sk)->v6_rcv_saddr) || (addr_type==IPV6_ADDR_MAPPED && sk2->family==AF_INET && inet_sk(sk)->rcv_saddr == inet_sk(sk2)->rcv_saddr)) break; + if (np2 != NULL) + if (!ipv6_addr_cmp(&np->rcv_saddr, + sk2->state != TCP_TIME_WAIT ? + &np2->rcv_saddr : + &((struct tcp_tw_bucket*)sk)->v6_rcv_saddr)) + break; } } } ---1463809535-1287385206-1024317093=:2496 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=decoded-oops Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME=decoded-oops a3N5bW9vcHMgMi40LjQgb24gaTY4NiAyLjQuMTktcHJlOC1hYzIuICBPcHRp b25zIHVzZWQNCiAgICAgLXYgL3Vzci9zcmMvbGludXgtMi41LjIxL3ZtbGlu dXggKHNwZWNpZmllZCkNCiAgICAgLUsgKHNwZWNpZmllZCkNCiAgICAgLUwg KHNwZWNpZmllZCkNCiAgICAgLW8gL2xpYi9tb2R1bGVzLzIuNS4yMS8gKHNw ZWNpZmllZCkNCiAgICAgLW0gL2Jvb3QvU3lzdGVtLm1hcC0yLjUuMjEgKHNw ZWNpZmllZCkNCg0KTm8gbW9kdWxlcyBpbiBrc3ltcywgc2tpcHBpbmcgb2Jq ZWN0cw0KVW5hYmxlIHRvIGhhbmRsZSBrZXJuZWwgTlVMTCBwb2ludGVyIGRl cmVmZXJlbmNlIGF0IHZpcnR1YWwgYWRkcmVzcyAwMDAwMDAxMA0KYzAyNzI0 NGUNCipwZGUgPSAwMDAwMDAwMA0KT29wczogMDAwMA0KQ1BVOiAgICAwDQpF SVA6ICAgIDAwMTA6WzxjMDI3MjQ0ZT5dICBOb3QgdGFpbnRlZA0KVXNpbmcg ZGVmYXVsdHMgZnJvbSBrc3ltb29wcyAtdCBlbGYzMi1pMzg2IC1hIGkzODYN CkVGTEFHUzogMDAwMTAyNDYNCmVheDogY2ZkNjhiMjggICBlYng6IGNlYTYw MzYwICAgICBlY3g6IDAwMDAwMDEwICAgICAgIGVkeDogY2ZkNjhhMGENCmVz aTogY2ZkNjhkZTggICBlZGk6IDAwMDAwMDEwICAgICBlYnA6IGNmOWNmMjYw ICAgICAgIGVzcDogY2U4YTdlOTgNCmRzOiAwMDE4ICAgZXM6IDAwMTggICBz czogMDAxOA0KU3RhY2s6ICBjZThhN2YxYyBjZmQ2OGFjMCBjZmQ2OGRlOCBj MDM0MTkwOCBjZmQ2OGRlOCAwMTAwMDA3ZiAwMDAwMDAxMSAwMDAwMDAwMQ0K ICAgICAgICBjZmQ2OGFjMCBjZmQyMWRjOCAwM2I5Mzg3NCBjMDI2MGY4MSBj ZmQ2OGFjMCAwMDAwMDNiOSBjZThhN2E0MCBjZThhN2YxNA0KICAgICAgICAw MDAwMDAxYyA0MDI2Mzg3NCAwMDAwMDAxMSAwM2I5MTljOCAwNjAwMDA3ZiBj ZmQ2OGRkOCBjZmQ2OGJmOCBjMDIyMjdjMA0KQ2FsbCBUcmFjZTogWzxjMDI2 MGY4MT5dIFs8YzAyMjI3YzA+XSBbYzAyMjM2Mjk+XSBbPGMwMjIxY2Y1Pl0g WzxjMDIyMmQyZT5dDQogICBbPGMwMjIyZDUwPl0gWzxjMDIyMzJhMD5dIFs8 YzAxMDZhMTc+XQ0KQ29kZTogZjMgYTYgNzQgMmMgODEgN2MgMjQgMTggMDAg MTAgMDAgMDAgNzUgMTcgNjYgODMgN2IgMWMgMDIgNzUNCg0KPj5FSVA7IGMw MjcyNDRlIDx0Y3BfdjZfZ2V0X3BvcnQrMWFlLzJkND4gICA8PT09PT0NClRy YWNlOyBjMDI2MGY4MSA8aW5ldDZfYmluZCsyYjEvM2Q4Pg0KVHJhY2U7IGMw MjIyN2MwIDxzeXNfYmluZCs1NC83ND4NClRyYWNlOyBjMDIyMmQ1MCA8c3lz X3NldHNvY2tvcHQrNmMvNzg+DQpUcmFjZTsgYzAyMjMyYTAgPHN5c19zb2Nr ZXRjYWxsKzc0LzFmYz4NClRyYWNlOyBjMDEwNmExNyA8c3lzY2FsbF9jYWxs KzcvYj4NCkNvZGU7ICBjMDI3MjQ0ZSA8dGNwX3Y2X2dldF9wb3J0KzFhZS8y ZDQ+DQowMDAwMDAwMCA8X0VJUD46DQpDb2RlOyAgYzAyNzI0NGUgPHRjcF92 Nl9nZXRfcG9ydCsxYWUvMmQ0PiAgIDw9PT09PQ0KICAgMDogICBmMyBhNiAg ICAgICAgICAgICAgICAgICAgIHJlcHogY21wc2IgJWVzOiglZWRpKSwlZHM6 KCVlc2kpICAgPD09PT09DQpDb2RlOyAgYzAyNzI0NTAgPHRjcF92Nl9nZXRf cG9ydCsxYjAvMmQ0Pg0KICAgMjogICA3NCAyYyAgICAgICAgICAgICAgICAg ICAgIGplICAgICAzMCA8X0VJUCsweDMwPiBjMDI3MjQ3ZSA8dGNwX3Y2X2dl dF9wb3J0KzFkZS8yZDQ+DQpDb2RlOyAgYzAyNzI0NTIgPHRjcF92Nl9nZXRf cG9ydCsxYjIvMmQ0Pg0KICAgNDogICA4MSA3YyAyNCAxOCAwMCAxMCAwMCAg ICAgIGNtcGwgICAkMHgxMDAwLDB4MTgoJWVzcCwxKQ0KQ29kZTsgIGMwMjcy NDU5IDx0Y3BfdjZfZ2V0X3BvcnQrMWI5LzJkND4NCiAgIGI6ICAgMDAgDQpD b2RlOyAgYzAyNzI0NWEgPHRjcF92Nl9nZXRfcG9ydCsxYmEvMmQ0Pg0KICAg YzogICA3NSAxNyAgICAgICAgICAgICAgICAgICAgIGpuZSAgICAyNSA8X0VJ UCsweDI1PiBjMDI3MjQ3MyA8dGNwX3Y2X2dldF9wb3J0KzFkMy8yZDQ+DQpD b2RlOyAgYzAyNzI0NWMgPHRjcF92Nl9nZXRfcG9ydCsxYmMvMmQ0Pg0KICAg ZTogICA2NiA4MyA3YiAxYyAwMiAgICAgICAgICAgIGNtcHcgICAkMHgyLDB4 MWMoJWVieCkNCkNvZGU7ICBjMDI3MjQ2MSA8dGNwX3Y2X2dldF9wb3J0KzFj MS8yZDQ+DQogIDEzOiAgIDc1IDAwICAgICAgICAgICAgICAgICAgICAgam5l ICAgIDE1IDxfRUlQKzB4MTU+IGMwMjcyNDYzIDx0Y3BfdjZfZ2V0X3BvcnQr MWMzLzJkND4NCg0K ---1463809535-1287385206-1024317093=:2496 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="ipv6-bind.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="ipv6-bind.c" I2luY2x1ZGUgPHN0ZGxpYi5oPg0KI2luY2x1ZGUgPHN0ZGlvLmg+DQojaW5j bHVkZSA8c3lzL3R5cGVzLmg+DQojaW5jbHVkZSA8c3lzL3NvY2tldC5oPg0K I2luY2x1ZGUgPG5ldGluZXQvaW4uaD4NCiNpbmNsdWRlIDxhcnBhL2luZXQu aD4NCg0KY29uc3QgdW5zaWduZWQgc2hvcnQgYmluZF9wb3J0ID0gNDUwMDsN Cg0KaW50IGRvX2lwdjRfYmluZChjaGFyICppcCwgY29uc3QgdW5zaWduZWQg c2hvcnQgcG9ydCkgew0KCXN0cnVjdCBzb2NrYWRkcl9pbiBhZGRyOw0KCWlu dCBzb2NrOw0KCWludCByZXQ7DQoJDQoJbWVtc2V0KCZhZGRyLCAweDAwLCBz aXplb2YoYWRkcikpOw0KCWFkZHIuc2luX2ZhbWlseSA9IEFGX0lORVQ7DQoJ YWRkci5zaW5fcG9ydCA9IGh0b25zKHBvcnQpOw0KCWluZXRfcHRvbihBRl9J TkVULCBpcCwgJihhZGRyLnNpbl9hZGRyKSk7DQoJDQoJcmV0ID0gc29ja2V0 KFBGX0lORVQsIFNPQ0tfU1RSRUFNLCAwKTsNCglpZihyZXQgPT0gLTEpIHsN CgkJcmV0dXJuIHJldDsNCgl9IGVsc2Ugew0KCQlzb2NrID0gcmV0Ow0KCX0N CglyZXQgPSBiaW5kKHNvY2ssIChzdHJ1Y3Qgc29ja2FkZHIgKikmYWRkciwg c2l6ZW9mKGFkZHIpKTsNCglpZihyZXQgPT0gLTEpIHsNCgkJcmV0dXJuIHJl dDsNCgl9IGVsc2Ugew0KCQlyZXR1cm4gc29jazsNCgl9DQp9DQoNCmludCBk b19pcHY2X2JpbmQoY2hhciAqaXAsIGNvbnN0IHVuc2lnbmVkIHNob3J0IHBv cnQpIHsNCglzdHJ1Y3Qgc29ja2FkZHJfaW42IGFkZHI7DQoJaW50IHNvY2s7 DQoJaW50IHJldDsNCgkNCgltZW1zZXQoJmFkZHIsIDB4MDAsIHNpemVvZihh ZGRyKSk7DQoJYWRkci5zaW42X2ZhbWlseSA9IEFGX0lORVQ2Ow0KCWFkZHIu c2luNl9wb3J0ID0gaHRvbnMocG9ydCk7DQoJaW5ldF9wdG9uKEFGX0lORVQ2 LCBpcCwgJihhZGRyLnNpbjZfYWRkcikpOw0KCQ0KCXJldCA9IHNvY2tldChQ Rl9JTkVUNiwgU09DS19TVFJFQU0sIDApOw0KCWlmKHJldCA9PSAtMSkgew0K CQlyZXR1cm4gcmV0Ow0KCX0gZWxzZSB7DQoJCXNvY2sgPSByZXQ7DQoJfQ0K DQoJcmV0ID0gYmluZChzb2NrLCAoc3RydWN0IHNvY2thZGRyICopJmFkZHIs IHNpemVvZihhZGRyKSk7DQoJaWYocmV0ID09IC0xKSB7DQoJCXJldHVybiBy ZXQ7DQoJfSBlbHNlIHsNCgkJcmV0dXJuIHNvY2s7DQoJfQ0KfQ0KDQppbnQg bWFpbih2b2lkKSB7DQoJaW50IGlwdjRfc29jayA9IDA7DQoJaW50IGlwdjZf c29jayA9IDA7DQoJaXB2NF9zb2NrID0gZG9faXB2NF9iaW5kKCIxMjcuMC4w LjEiLCBiaW5kX3BvcnQpOw0KCWlwdjZfc29jayA9IGRvX2lwdjZfYmluZCgi OjoxIiwgYmluZF9wb3J0KTsNCglpZihpcHY0X3NvY2sgPCAwKSB7DQoJCXBy aW50ZigiaXB2NCBiaW5kIGZhaWxlZFxuIik7DQoJfSBlbHNlIHsNCgkJcHJp bnRmKCJpcHY0IGJpbmQgc3VjY2VlZGVkXG4iKTsNCgkJY2xvc2UoaXB2NF9z b2NrKTsNCgl9DQoJaWYoaXB2Nl9zb2NrIDwgMCkgew0KCQlwcmludGYoImlw djYgYmluZCBmYWlsZWRcbiIpOw0KCX0gZWxzZSB7DQoJCXByaW50ZigiaXB2 NiBiaW5kIHN1Y2NlZWRlZFxuIik7DQoJCWNsb3NlKGlwdjZfc29jayk7DQoJ fQ0KCXJldHVybiAwOw0KfQ0K ---1463809535-1287385206-1024317093=:2496-- From owner-netdev@oss.sgi.com Mon Jun 17 14:35:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5HLZknC030878 for ; Mon, 17 Jun 2002 14:35:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5HLZkaQ030877 for netdev-outgoing; Mon, 17 Jun 2002 14:35:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5HLZinC030874 for ; Mon, 17 Jun 2002 14:35:44 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id OAA13270; Mon, 17 Jun 2002 14:33:19 -0700 Date: Mon, 17 Jun 2002 14:33:19 -0700 (PDT) Message-Id: <20020617.143319.54623892.davem@redhat.com> To: critson@perlfu.co.uk Cc: torvalds@transmeta.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH][2.5.22] OOPS in tcp_v6_get_port From: "David S. Miller" In-Reply-To: References: X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 208 Lines: 5 This is a known bug introduced by the struct sock splitup into external per-protocol pieces done by Arnaldo de Melo. He is working on the proper fix, your proposed change will just paper over the real bug. From owner-netdev@oss.sgi.com Mon Jun 17 17:55:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5I0t6nC000447 for ; Mon, 17 Jun 2002 17:55:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5I0t5XI000446 for netdev-outgoing; Mon, 17 Jun 2002 17:55:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from orion.netbank.com.br ([200.203.199.90]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5I0stnC000441 for ; Mon, 17 Jun 2002 17:54:56 -0700 Received: from [200.181.171.135] (helo=brinquendo.conectiva.com.br) by orion.netbank.com.br with esmtp (Exim 3.33 #1) id 17K7Ec-00060T-00; Mon, 17 Jun 2002 21:52:38 -0300 Received: by brinquendo.conectiva.com.br (Postfix, from userid 500) id E71EC1966C; Mon, 17 Jun 2002 21:57:35 -0300 (BRT) Date: Mon, 17 Jun 2002 21:57:35 -0300 From: Arnaldo Carvalho de Melo To: "David S. Miller" Cc: critson@perlfu.co.uk, torvalds@transmeta.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH][2.5.22] OOPS in tcp_v6_get_port Message-ID: <20020618005735.GB1146@conectiva.com.br> Mail-Followup-To: Arnaldo Carvalho de Melo , "David S. Miller" , critson@perlfu.co.uk, torvalds@transmeta.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com References: <20020617.143319.54623892.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020617.143319.54623892.davem@redhat.com> User-Agent: Mutt/1.4i X-Url: http://advogato.org/person/acme Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1683 Lines: 62 Em Mon, Jun 17, 2002 at 02:33:19PM -0700, David S. Miller escreveu: > > This is a known bug introduced by the struct sock splitup into > external per-protocol pieces done by Arnaldo de Melo. He is working > on the proper fix, your proposed change will just paper over the real > bug. Carl, Can you try this patch? - Arnaldo --- orig/net/ipv6/tcp_ipv6.c Sat May 25 23:13:56 2002 +++ linux/net/ipv6/tcp_ipv6.c Fri Jun 14 23:23:07 2002 @@ -1240,6 +1240,7 @@ struct dst_entry *dst) { struct ipv6_pinfo *newnp, *np = inet6_sk(sk); + struct tcp6_sock *newtcp6sk; struct flowi fl; struct inet_opt *newinet; struct tcp_opt *newtp; @@ -1256,10 +1257,15 @@ if (newsk == NULL) return NULL; + newtcp6sk = (struct tcp6_sock *)newsk; + newtcp6sk->pinet6 = &newtcp6sk->inet6; + newinet = inet_sk(newsk); newnp = inet6_sk(newsk); newtp = tcp_sk(newsk); + memcpy(newnp, np, sizeof(struct ipv6_pinfo)); + ipv6_addr_set(&newnp->daddr, 0, 0, htonl(0x0000FFFF), newinet->daddr); @@ -1336,9 +1342,15 @@ ip6_dst_store(newsk, dst, NULL); sk->route_caps = dst->dev->features&~NETIF_F_IP_CSUM; + newtcp6sk = (struct tcp6_sock *)newsk; + newtcp6sk->pinet6 = &newtcp6sk->inet6; + newtp = tcp_sk(newsk); newinet = inet_sk(newsk); newnp = inet6_sk(newsk); + + memcpy(newnp, np, sizeof(struct ipv6_pinfo)); + ipv6_addr_copy(&newnp->daddr, &req->af.v6_req.rmt_addr); ipv6_addr_copy(&newnp->saddr, &req->af.v6_req.loc_addr); ipv6_addr_copy(&newnp->rcv_saddr, &req->af.v6_req.loc_addr); -- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html From owner-netdev@oss.sgi.com Mon Jun 17 19:20:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5I2KDnC001281 for ; Mon, 17 Jun 2002 19:20:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5I2KDrg001280 for netdev-outgoing; Mon, 17 Jun 2002 19:20:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5I2KAnC001277 for ; Mon, 17 Jun 2002 19:20:10 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id TAA15993; Mon, 17 Jun 2002 19:17:27 -0700 Date: Mon, 17 Jun 2002 19:17:26 -0700 (PDT) Message-Id: <20020617.191726.55300824.davem@redhat.com> To: acme@conectiva.com.br Cc: critson@perlfu.co.uk, torvalds@transmeta.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH][2.5.22] OOPS in tcp_v6_get_port From: "David S. Miller" In-Reply-To: <20020618005735.GB1146@conectiva.com.br> References: <20020617.143319.54623892.davem@redhat.com> <20020618005735.GB1146@conectiva.com.br> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 332 Lines: 10 From: Arnaldo Carvalho de Melo Date: Mon, 17 Jun 2002 21:57:35 -0300 --- orig/net/ipv6/tcp_ipv6.c Sat May 25 23:13:56 2002 +++ linux/net/ipv6/tcp_ipv6.c Fri Jun 14 23:23:07 2002 I've installed this change into my tree in the meantime. If we find a better fix, we can just revert this. Thanks. From owner-netdev@oss.sgi.com Mon Jun 17 19:47:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5I2lBnC001608 for ; Mon, 17 Jun 2002 19:47:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5I2lBS9001607 for netdev-outgoing; Mon, 17 Jun 2002 19:47:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from orion.netbank.com.br ([200.203.199.90]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5I2l5nC001603 for ; Mon, 17 Jun 2002 19:47:07 -0700 Received: from [200.181.171.135] (helo=brinquendo.conectiva.com.br) by orion.netbank.com.br with esmtp (Exim 3.33 #1) id 17K8zB-00063v-00; Mon, 17 Jun 2002 23:44:51 -0300 Received: by brinquendo.conectiva.com.br (Postfix, from userid 500) id 6C0401966C; Mon, 17 Jun 2002 23:49:35 -0300 (BRT) Date: Mon, 17 Jun 2002 23:49:34 -0300 From: Arnaldo Carvalho de Melo To: "David S. Miller" Cc: critson@perlfu.co.uk, torvalds@transmeta.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH][2.5.22] OOPS in tcp_v6_get_port Message-ID: <20020618024934.GA4274@conectiva.com.br> Mail-Followup-To: Arnaldo Carvalho de Melo , "David S. Miller" , critson@perlfu.co.uk, torvalds@transmeta.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com References: <20020617.143319.54623892.davem@redhat.com> <20020618005735.GB1146@conectiva.com.br> <20020617.191726.55300824.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020617.191726.55300824.davem@redhat.com> User-Agent: Mutt/1.4i X-Url: http://advogato.org/person/acme Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 623 Lines: 15 Em Mon, Jun 17, 2002 at 07:17:26PM -0700, David S. Miller escreveu: > From: Arnaldo Carvalho de Melo > Date: Mon, 17 Jun 2002 21:57:35 -0300 > > --- orig/net/ipv6/tcp_ipv6.c Sat May 25 23:13:56 2002 > +++ linux/net/ipv6/tcp_ipv6.c Fri Jun 14 23:23:07 2002 > > I've installed this change into my tree in the meantime. > If we find a better fix, we can just revert this. OK, I found a better fix, I think, that allowed me to kill inet6_sk_generic in af_inet6.c, using a constructor for the tcpv6, udpv6 and raw6 slab caches, as suggested by Russel King, I'll be sending RSN. - Arnaldo From owner-netdev@oss.sgi.com Mon Jun 17 20:55:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5I3twnC002868 for ; Mon, 17 Jun 2002 20:55:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5I3twBj002867 for netdev-outgoing; Mon, 17 Jun 2002 20:55:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from garrincha.netbank.com.br (garrincha.netbank.com.br [200.203.199.88]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5I3tbnC002864 for ; Mon, 17 Jun 2002 20:55:38 -0700 Received: (qmail 19568 invoked by uid 84); 18 Jun 2002 04:00:58 -0000 Received: from acme@conectiva.com.br by garrincha.netbank.com.br with qmail-scanner-1.01 (. Clean. Processed in 3.007929 secs); 18 Jun 2002 04:00:58 -0000 Received: from 3-135.ctame701-2.telepar.net.br (HELO brinquendo.conectiva.com.br) (200.181.171.135) by garrincha.netbank.com.br with SMTP; 18 Jun 2002 04:00:55 -0000 Received: by brinquendo.conectiva.com.br (Postfix, from userid 500) id 92B041966C; Tue, 18 Jun 2002 00:58:05 -0300 (BRT) Date: Tue, 18 Jun 2002 00:58:04 -0300 From: Arnaldo Carvalho de Melo To: "David S. Miller" , critson@perlfu.co.uk, torvalds@transmeta.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [BKPATCH] Re: [PATCH][2.5.22] OOPS in tcp_v6_get_port Message-ID: <20020618035804.GA18759@conectiva.com.br> Mail-Followup-To: Arnaldo Carvalho de Melo , "David S. Miller" , critson@perlfu.co.uk, torvalds@transmeta.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com References: <20020617.143319.54623892.davem@redhat.com> <20020618005735.GB1146@conectiva.com.br> <20020617.191726.55300824.davem@redhat.com> <20020618024934.GA4274@conectiva.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020618024934.GA4274@conectiva.com.br> User-Agent: Mutt/1.4i X-Url: http://advogato.org/person/acme Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 5383 Lines: 154 Em Mon, Jun 17, 2002 at 11:49:34PM -0300, Arnaldo C. Melo escreveu: > Em Mon, Jun 17, 2002 at 07:17:26PM -0700, David S. Miller escreveu: > > From: Arnaldo Carvalho de Melo > > Date: Mon, 17 Jun 2002 21:57:35 -0300 > > > > --- orig/net/ipv6/tcp_ipv6.c Sat May 25 23:13:56 2002 > > +++ linux/net/ipv6/tcp_ipv6.c Fri Jun 14 23:23:07 2002 > > > > I've installed this change into my tree in the meantime. > > If we find a better fix, we can just revert this. > > OK, I found a better fix, I think, that allowed me to kill inet6_sk_generic > in af_inet6.c, using a constructor for the tcpv6, udpv6 and raw6 slab caches, > as suggested by Russel King, I'll be sending RSN. Here it is, David, please consider pulling it from: http://kernel-acme.bkbits.net:8080/tcpv6-pinet6 Best Regards, - Arnaldo # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.656 -> 1.657 # net/ipv6/tcp_ipv6.c 1.17 -> 1.18 # net/ipv6/af_inet6.c 1.8 -> 1.9 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 02/06/18 acme@conectiva.com.br 1.657 # net/ipv6/af_inet6.c # net/ipv6/tcp_ipv6.c # # - Add constructors for the tcp6_sk_cachep, udp6_sk_cachep and raw6_sk_cachep slab caches, # to initialize ->pinet6 to the respective &->inet6, this simplifies inet6_create, # making ipv6_sk_generic not needed and fixing a bug where we create a new tcpv6 socket # outside inet6_create and we were not initializing ->pinet6 properly, thanks to # Russell King for pointing out the bug and doing the initial analisys that made the # fix easy to make. # -------------------------------------------- # diff -Nru a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c --- a/net/ipv6/af_inet6.c Mon Mar 11 11:13:05 2002 +++ b/net/ipv6/af_inet6.c Tue Jun 18 00:27:30 2002 @@ -134,23 +134,11 @@ return rc; } -static __inline__ struct ipv6_pinfo *inet6_sk_generic(struct sock *sk) -{ - struct ipv6_pinfo *rc = (&((struct tcp6_sock *)sk)->inet6); - - if (sk->protocol == IPPROTO_UDP) - rc = (&((struct udp6_sock *)sk)->inet6); - else if (sk->protocol == IPPROTO_RAW) - rc = (&((struct raw6_sock *)sk)->inet6); - return rc; -} - static int inet6_create(struct socket *sock, int protocol) { struct inet_opt *inet; struct ipv6_pinfo *np; struct sock *sk; - struct tcp6_sock* tcp6sk; struct list_head *p; struct inet_protosw *answer; @@ -212,8 +200,7 @@ sk->backlog_rcv = answer->prot->backlog_rcv; - tcp6sk = (struct tcp6_sock *)sk; - tcp6sk->pinet6 = np = inet6_sk_generic(sk); + np = inet6_sk(sk); np->hop_limit = -1; np->mcast_hops = -1; np->mc_loop = 1; @@ -632,6 +619,30 @@ inet_unregister_protosw(p); } +static void tcp6_pinet6_init(void *foo, kmem_cache_t *cachep, + unsigned long flags) +{ + struct tcp6_sock *tcp6sk = (struct tcp6_sock *)foo; + + tcp6sk->pinet6 = &tcp6sk->inet6; +} + +static void udp6_pinet6_init(void *foo, kmem_cache_t *cachep, + unsigned long flags) +{ + struct udp6_sock *udp6sk = (struct udp6_sock *)foo; + + udp6sk->pinet6 = &udp6sk->inet6; +} + +static void raw6_pinet6_init(void *foo, kmem_cache_t *cachep, + unsigned long flags) +{ + struct raw6_sock *raw6sk = (struct raw6_sock *)foo; + + raw6sk->pinet6 = &raw6sk->inet6; +} + static int __init inet6_init(void) { struct sk_buff *dummy_skb; @@ -655,13 +666,16 @@ /* allocate our sock slab caches */ tcp6_sk_cachep = kmem_cache_create("tcp6_sock", sizeof(struct tcp6_sock), 0, - SLAB_HWCACHE_ALIGN, 0, 0); + SLAB_HWCACHE_ALIGN, + tcp6_pinet6_init, NULL); udp6_sk_cachep = kmem_cache_create("udp6_sock", sizeof(struct udp6_sock), 0, - SLAB_HWCACHE_ALIGN, 0, 0); + SLAB_HWCACHE_ALIGN, + udp6_pinet6_init, NULL); raw6_sk_cachep = kmem_cache_create("raw6_sock", sizeof(struct raw6_sock), 0, - SLAB_HWCACHE_ALIGN, 0, 0); + SLAB_HWCACHE_ALIGN, + raw6_pinet6_init, NULL); if (!tcp6_sk_cachep || !udp6_sk_cachep || !raw6_sk_cachep) printk(KERN_CRIT __FUNCTION__ ": Can't create protocol sock SLAB caches!\n"); diff -Nru a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c --- a/net/ipv6/tcp_ipv6.c Wed May 22 15:16:37 2002 +++ b/net/ipv6/tcp_ipv6.c Tue Jun 18 00:27:30 2002 @@ -1260,6 +1260,8 @@ newnp = inet6_sk(newsk); newtp = tcp_sk(newsk); + memcpy(newnp, np, sizeof(struct ipv6_pinfo)); + ipv6_addr_set(&newnp->daddr, 0, 0, htonl(0x0000FFFF), newinet->daddr); @@ -1339,6 +1341,7 @@ newtp = tcp_sk(newsk); newinet = inet_sk(newsk); newnp = inet6_sk(newsk); + memcpy(newnp, np, sizeof(struct ipv6_pinfo)); ipv6_addr_copy(&newnp->daddr, &req->af.v6_req.rmt_addr); ipv6_addr_copy(&newnp->saddr, &req->af.v6_req.loc_addr); ipv6_addr_copy(&newnp->rcv_saddr, &req->af.v6_req.loc_addr); From owner-netdev@oss.sgi.com Mon Jun 17 21:13:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5I4DDnC003110 for ; Mon, 17 Jun 2002 21:13:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5I4DD4j003109 for netdev-outgoing; Mon, 17 Jun 2002 21:13:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from garrincha.netbank.com.br (garrincha.netbank.com.br [200.203.199.88]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5I4D6nC003105 for ; Mon, 17 Jun 2002 21:13:07 -0700 Received: (qmail 25417 invoked by uid 84); 18 Jun 2002 04:18:30 -0000 Received: from acme@conectiva.com.br by garrincha.netbank.com.br with qmail-scanner-1.01 (. Clean. Processed in 1.570168 secs); 18 Jun 2002 04:18:30 -0000 Received: from 3-135.ctame701-2.telepar.net.br (HELO brinquendo.conectiva.com.br) (200.181.171.135) by garrincha.netbank.com.br with SMTP; 18 Jun 2002 04:18:28 -0000 Received: by brinquendo.conectiva.com.br (Postfix, from userid 500) id 56F5A1966C; Tue, 18 Jun 2002 01:15:39 -0300 (BRT) Date: Tue, 18 Jun 2002 01:15:39 -0300 From: Arnaldo Carvalho de Melo To: "David S. Miller" , critson@perlfu.co.uk, torvalds@transmeta.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [BKPATCH] Re: [PATCH][2.5.22] OOPS in tcp_v6_get_port Message-ID: <20020618041539.GB18759@conectiva.com.br> Mail-Followup-To: Arnaldo Carvalho de Melo , "David S. Miller" , critson@perlfu.co.uk, torvalds@transmeta.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com References: <20020617.143319.54623892.davem@redhat.com> <20020618005735.GB1146@conectiva.com.br> <20020617.191726.55300824.davem@redhat.com> <20020618024934.GA4274@conectiva.com.br> <20020618035804.GA18759@conectiva.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020618035804.GA18759@conectiva.com.br> User-Agent: Mutt/1.4i X-Url: http://advogato.org/person/acme Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1171 Lines: 29 Em Tue, Jun 18, 2002 at 12:58:04AM -0300, Arnaldo C. Melo escreveu: > Em Mon, Jun 17, 2002 at 11:49:34PM -0300, Arnaldo C. Melo escreveu: > > Em Mon, Jun 17, 2002 at 07:17:26PM -0700, David S. Miller escreveu: > > > From: Arnaldo Carvalho de Melo > > > Date: Mon, 17 Jun 2002 21:57:35 -0300 > > > > > > --- orig/net/ipv6/tcp_ipv6.c Sat May 25 23:13:56 2002 > > > +++ linux/net/ipv6/tcp_ipv6.c Fri Jun 14 23:23:07 2002 > > > > > > I've installed this change into my tree in the meantime. > > > If we find a better fix, we can just revert this. > > > > OK, I found a better fix, I think, that allowed me to kill inet6_sk_generic > > in af_inet6.c, using a constructor for the tcpv6, udpv6 and raw6 slab caches, > > as suggested by Russel King, I'll be sending RSN. > > Here it is, David, please consider pulling it from: > > http://kernel-acme.bkbits.net:8080/tcpv6-pinet6 > > Best Regards, > > - Arnaldo Oops, brain fart, David, please don't apply, in tcp_create_openreq_child we overwrite the ->pinet6 field after the constructor inits it to the proper value :( Please leave the old patch in place for a while... :( - Arnaldo From owner-netdev@oss.sgi.com Mon Jun 17 21:19:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5I4JlnC003240 for ; Mon, 17 Jun 2002 21:19:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5I4JlCY003239 for netdev-outgoing; Mon, 17 Jun 2002 21:19:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5I4JinC003236 for ; Mon, 17 Jun 2002 21:19:44 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id VAA16446; Mon, 17 Jun 2002 21:17:22 -0700 Date: Mon, 17 Jun 2002 21:17:21 -0700 (PDT) Message-Id: <20020617.211721.123286561.davem@redhat.com> To: acme@conectiva.com.br Cc: critson@perlfu.co.uk, torvalds@transmeta.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [BKPATCH] Re: [PATCH][2.5.22] OOPS in tcp_v6_get_port From: "David S. Miller" In-Reply-To: <20020618041539.GB18759@conectiva.com.br> References: <20020618024934.GA4274@conectiva.com.br> <20020618035804.GA18759@conectiva.com.br> <20020618041539.GB18759@conectiva.com.br> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 338 Lines: 8 From: Arnaldo Carvalho de Melo Date: Tue, 18 Jun 2002 01:15:39 -0300 Oops, brain fart, David, please don't apply, in tcp_create_openreq_child we overwrite the ->pinet6 field after the constructor inits it to the proper value :( Please leave the old patch in place for a while... :( No problem. From owner-netdev@oss.sgi.com Tue Jun 18 00:36:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5I7aHnC009264 for ; Tue, 18 Jun 2002 00:36:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5I7aHmr009263 for netdev-outgoing; Tue, 18 Jun 2002 00:36:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from lain.perlfu.co.uk (IDENT:root@pc1-camb4-0-cust108.cam.cable.ntl.com [62.253.133.108]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5I7aCnC009256 for ; Tue, 18 Jun 2002 00:36:13 -0700 Received: from lain.perlfu.co.uk ([192.168.1.10] ident=critson) by lain.perlfu.co.uk with esmtp (Exim 3.34 #5) id 17KDZg-0000U1-00; Tue, 18 Jun 2002 08:38:48 +0100 Date: Tue, 18 Jun 2002 08:38:48 +0100 (BST) From: Carl Ritson To: Arnaldo Carvalho de Melo cc: "David S. Miller" , Linus Torvalds , Linux Kernel Mailing List , Subject: Re: [PATCH][2.5.22] OOPS in tcp_v6_get_port In-Reply-To: <20020618005735.GB1146@conectiva.com.br> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 734 Lines: 27 On Mon, 17 Jun 2002, Arnaldo Carvalho de Melo wrote: > Em Mon, Jun 17, 2002 at 02:33:19PM -0700, David S. Miller escreveu: > > > > This is a known bug introduced by the struct sock splitup into > > external per-protocol pieces done by Arnaldo de Melo. He is working > > on the proper fix, your proposed change will just paper over the real > > bug. I suspected something like that. > Carl, > > Can you try this patch? > > - Arnaldo > > --- orig/net/ipv6/tcp_ipv6.c Sat May 25 23:13:56 2002 > +++ linux/net/ipv6/tcp_ipv6.c Fri Jun 14 23:23:07 2002 > This patch doesn't help, it produces exactly the same oops when decoded, I assume the newer patch you mention to Dave is the correct fix? Thanks, Carl From owner-netdev@oss.sgi.com Tue Jun 18 02:41:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5I9fPnC010641 for ; Tue, 18 Jun 2002 02:41:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5I9fPsB010640 for netdev-outgoing; Tue, 18 Jun 2002 02:41:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sex.inr.ac.ru (sex.inr.ac.ru [193.233.7.165]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5I9fLnC010636 for ; Tue, 18 Jun 2002 02:41:22 -0700 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id NAA12296; Tue, 18 Jun 2002 13:43:21 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200206180943.NAA12296@sex.inr.ac.ru> Subject: Re: [PATCH][2.5.22] OOPS in tcp_v6_get_port To: davem@redhat.COM (David S. Miller) Date: Tue, 18 Jun 2002 13:43:21 +0400 (MSD) Cc: netdev@oss.sgi.com In-Reply-To: <20020617.143319.54623892.davem@redhat.com> from "David S. Miller" at Jun 18, 2 01:45:00 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 550 Lines: 17 Hello! > This is a known bug introduced by the struct sock splitup into > external per-protocol pieces done by Arnaldo de Melo. He is working > on the proper fix, your proposed change will just paper over the real > bug. I am afraid you speak about different bug. Old code really relied on the fact that each IPv4 code has zeroed IPv6 part, and that each IPv6 socket has correctly intialized IPv4 part. So, Carl's suggestion may be right. Each time when accesing IPv6 data we have to check that it really exists (when we are not sure). Alexey From owner-netdev@oss.sgi.com Tue Jun 18 03:01:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5IA14nC010923 for ; Tue, 18 Jun 2002 03:01:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IA14vC010922 for netdev-outgoing; Tue, 18 Jun 2002 03:01:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IA12nC010919 for ; Tue, 18 Jun 2002 03:01:02 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id CAA17452; Tue, 18 Jun 2002 02:58:12 -0700 Date: Tue, 18 Jun 2002 02:58:11 -0700 (PDT) Message-Id: <20020618.025811.36457258.davem@redhat.com> To: kuznet@ms2.inr.ac.ru Cc: netdev@oss.sgi.com Subject: Re: [PATCH][2.5.22] OOPS in tcp_v6_get_port From: "David S. Miller" In-Reply-To: <200206180943.NAA12296@sex.inr.ac.ru> References: <20020617.143319.54623892.davem@redhat.com> <200206180943.NAA12296@sex.inr.ac.ru> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 206 Lines: 7 From: kuznet@ms2.inr.ac.ru Date: Tue, 18 Jun 2002 13:43:21 +0400 (MSD) I am afraid you speak about different bug. It is different bug, indeed. The oops looked very similar, it tricked me :-) From owner-netdev@oss.sgi.com Tue Jun 18 04:49:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5IBn5nC012749 for ; Tue, 18 Jun 2002 04:49:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IBn5Hg012748 for netdev-outgoing; Tue, 18 Jun 2002 04:49:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from balu.sch.bme.hu (balu.sch.bme.hu [152.66.208.40]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IBmvnC012739 for ; Tue, 18 Jun 2002 04:49:01 -0700 Received: (from kisza@localhost) by balu.sch.bme.hu (8.12.1/8.12.1) id g5IBpnts025588 for netdev@oss.sgi.com; Tue, 18 Jun 2002 13:51:49 +0200 (MEST) Date: Tue, 18 Jun 2002 13:51:49 +0200 From: Andras Kis-Szabo To: netdev@oss.sgi.com Subject: net/ipv6/exthdrs.c Message-ID: <20020618135149.A24751@sch.bme.hu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i X-Organization: SecurityAudit.hu X-GSM: +36-20-464-23-90 X-PGP-Fingerprint: 668B 0727 93F1 BD61 51F1 3971 9EBB 2798 E295 F49F X-PGP-KeyID: E295F49F X-Operating-System: SunOS 5.8 sun4u sparc SUNW,Ultra-2 X-PGP-Key-Expire: 01.01.2003. Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 643 Lines: 21 Hi, It's just a short question... Is there any plan to add the ESP header to the ipv6_ext_hdr() function (as a known header)? (It requires changes in this file and in the icmp.c at the first round.) Some user noticed that the Netfilter contains a very similar function, which knows the ESP. If this functon remains untouched, I'll add an another one into the Netfilter code (which can be used at the special matches). Regards, kisza -- Andras Kis-Szabo Security Development, Design and Audit -------------------------/ Zorp, NetFilter and IPv6 kisza@SecurityAudit.hu /-----Member of the BUTE-MIS-SEARCHlab----------> From owner-netdev@oss.sgi.com Tue Jun 18 04:57:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5IBvknC012975 for ; Tue, 18 Jun 2002 04:57:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IBvjgH012974 for netdev-outgoing; Tue, 18 Jun 2002 04:57:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IBvfnC012971 for ; Tue, 18 Jun 2002 04:57:42 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5IC0M826331; Tue, 18 Jun 2002 15:00:23 +0300 Date: Tue, 18 Jun 2002 15:00:22 +0300 (EEST) From: Pekka Savola To: Andras Kis-Szabo cc: netdev@oss.sgi.com Subject: Re: net/ipv6/exthdrs.c In-Reply-To: <20020618135149.A24751@sch.bme.hu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 760 Lines: 18 On Tue, 18 Jun 2002, Andras Kis-Szabo wrote: > Is there any plan to add the ESP header to the ipv6_ext_hdr() function (as a > known header)? > (It requires changes in this file and in the icmp.c at the first round.) Quickly looking at it, I don't know if adding it would help any (on the countrary). The code seems to be used mainly to skip over extension headers (forbidden, strictly speaking) when generating ICMP messages; in the case of ESP, the rest of the payload should be encrypted so adding it to the list would probably not change anything? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-netdev@oss.sgi.com Tue Jun 18 06:49:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5IDnhnC015250 for ; Tue, 18 Jun 2002 06:49:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IDnhrJ015249 for netdev-outgoing; Tue, 18 Jun 2002 06:49:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from balu.sch.bme.hu (balu.sch.bme.hu [152.66.208.40]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IDnanC015246 for ; Tue, 18 Jun 2002 06:49:36 -0700 Received: (from kisza@localhost) by balu.sch.bme.hu (8.12.1/8.12.1) id g5IDoLlx014330; Tue, 18 Jun 2002 15:50:21 +0200 (MEST) Date: Tue, 18 Jun 2002 15:50:21 +0200 From: Andras Kis-Szabo To: Pekka Savola Cc: netdev@oss.sgi.com Subject: Re: net/ipv6/exthdrs.c Message-ID: <20020618155021.A12974@sch.bme.hu> References: <20020618135149.A24751@sch.bme.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i X-Organization: SecurityAudit.hu X-GSM: +36-20-464-23-90 X-PGP-Fingerprint: 668B 0727 93F1 BD61 51F1 3971 9EBB 2798 E295 F49F X-PGP-KeyID: E295F49F X-Operating-System: SunOS 5.8 sun4u sparc SUNW,Ultra-2 X-PGP-Key-Expire: 01.01.2003. X-MIME-Autoconverted: from 8bit to quoted-printable by balu.sch.bme.hu id g5IDoLlx014330 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g5IDnbnC015247 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1731 Lines: 40 Pekka Savola ........................................ (2002. június 18.) Hi! > > Is there any plan to add the ESP header to the ipv6_ext_hdr() function (as a > > known header)? > > (It requires changes in this file and in the icmp.c at the first round.) > Quickly looking at it, I don't know if adding it would help any (on the > countrary). At the firewall side the ESP is a known extension header. The ESP contains some field which can be parsed in a strict firewall rule. When the extension headers and the main header parsed by the Netfilter, the upper level protocol should be passed to the next level for future parsing. The implementation follows the standard where the ESP is one of the extension headers. BTW, the Netfilter code can be changed to this behaviour. (Minor changes in some file and a major change in the ESP match.) The ipv6_ext_hdr() could be exported? It would be usefull at the Netfilter side. (And when we are there: the ipv6_skip_exthdr() should be exported, too.) > The code seems to be used mainly to skip over extension headers > (forbidden, strictly speaking) when generating ICMP messages; in the case > of ESP, the rest of the payload should be encrypted so adding it to the > list would probably not change anything? At first look in the ipv6_skip_exthdr() in the parser loop: - if (nexthdr == NEXTHDR_NONE) + if ( (nexthdr == NEXTHDR_NONE) || (nexthdr == NEXTHDR_ESP) ) But after this change the ICMPv6 reply won't contain the ESP ... Regards, kisza -- Andras Kis-Szabo Security Development, Design and Audit -------------------------/ Zorp, NetFilter and IPv6 kisza@SecurityAudit.hu /-----Member of the BUTE-MIS-SEARCHlab----------> From owner-netdev@oss.sgi.com Tue Jun 18 06:58:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5IDwAnC015531 for ; Tue, 18 Jun 2002 06:58:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IDwAC0015530 for netdev-outgoing; Tue, 18 Jun 2002 06:58:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from balu.sch.bme.hu (balu.sch.bme.hu [152.66.208.40]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IDw2nC015521 for ; Tue, 18 Jun 2002 06:58:03 -0700 Received: (from kisza@localhost) by balu.sch.bme.hu (8.12.1/8.12.1) id g5IE0sLL015705 for netdev@oss.sgi.com; Tue, 18 Jun 2002 16:00:54 +0200 (MEST) Date: Tue, 18 Jun 2002 16:00:54 +0200 From: Andras Kis-Szabo To: netdev@oss.sgi.com Subject: [PATCH] Re: net/ipv6/exthdrs.c Message-ID: <20020618160054.B12974@sch.bme.hu> References: <20020618135149.A24751@sch.bme.hu> <20020618155021.A12974@sch.bme.hu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline In-Reply-To: <20020618155021.A12974@sch.bme.hu> User-Agent: Mutt/1.3.23i X-Organization: SecurityAudit.hu X-GSM: +36-20-464-23-90 X-PGP-Fingerprint: 668B 0727 93F1 BD61 51F1 3971 9EBB 2798 E295 F49F X-PGP-KeyID: E295F49F X-Operating-System: SunOS 5.8 sun4u sparc SUNW,Ultra-2 X-PGP-Key-Expire: 01.01.2003. Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1373 Lines: 56 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balu.sch.bme.hu id g5IE0sLL015705 Andras Kis-Szabo .................................... (2002. j=FAnius 18.= ) Hi! > The ipv6_ext_hdr() could be exported? It would be usefull at the Netfil= ter > side. > (And when we are there: the ipv6_skip_exthdr() should be exported, too.= ) I attached the patch for this. (If accepted, the Netfilter will follow it= s behaviour and I'll modify the matches.) Regards, kisza --=20 Andras Kis-Szabo Security Development, Design and Audit -------------------------/ Zorp, NetFilter and IPv6 kisza@SecurityAudit.hu /-----Member of the BUTE-MIS-SEARCHlab----------> --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=patch --- linux.old/net/ipv6/exthdrs.c Tue Jun 18 15:54:19 2002 +++ linux/net/ipv6/exthdrs.c Tue Jun 18 15:55:34 2002 @@ -20,6 +20,8 @@ * tlv options. */ +#include +#include #include #include #include @@ -804,4 +806,7 @@ *nexthdrp = nexthdr; return start; } + +EXPORT_SYMBOL(ipv6_ext_hdr); +EXPORT_SYMBOL(ipv6_skip_exthdr); --y0ulUmNC+osPPQO6-- From owner-netdev@oss.sgi.com Tue Jun 18 12:01:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5IJ1nnC030125 for ; Tue, 18 Jun 2002 12:01:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IJ1nL1030124 for netdev-outgoing; Tue, 18 Jun 2002 12:01:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sex.inr.ac.ru (sex.inr.ac.ru [193.233.7.165]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IJ1inC030121 for ; Tue, 18 Jun 2002 12:01:45 -0700 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id XAA13710; Tue, 18 Jun 2002 23:03:41 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200206181903.XAA13710@sex.inr.ac.ru> Subject: Re: net/ipv6/exthdrs.c To: kisza@securityaudit.HU (Andras Kis-Szabo) Date: Tue, 18 Jun 2002 23:03:41 +0400 (MSD) Cc: netdev@oss.sgi.com In-Reply-To: <20020618135149.A24751@sch.bme.hu> from "Andras Kis-Szabo" at Jun 18, 2 04:15:01 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 747 Lines: 23 Hello! > Is there any plan to add the ESP header to the ipv6_ext_hdr() function (as a > known header)? No, ESP is not a normal extension header, it terminates parse. So, ipv6_skip_headers cannot skip it. BTW the same is with netfilter. I do not see how are you going to use it. :-) > (It requires changes in this file and in the icmp.c at the first round.) I am afraid this will simply break the function. > If this functon remains untouched, I'll add an another one into the Netfilter > code (which can be used at the special matches). This may be right even not depending on this issue. Goals are different: the function in exthdrs.c does the best efforts to guess what protocol is, the function in netfilter should be paranoid. Alexey From owner-netdev@oss.sgi.com Tue Jun 18 12:08:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5IJ8YnC030461 for ; Tue, 18 Jun 2002 12:08:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IJ8Y8v030460 for netdev-outgoing; Tue, 18 Jun 2002 12:08:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from gw.icm.edu.pl (gw.icm.edu.pl [212.87.0.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IJ8QnC030454 for ; Tue, 18 Jun 2002 12:08:27 -0700 Received: from rekin.icm.edu.pl (IDENT:SF62ZHml0EYTaRejgVwCU8V5cPz9XKOD@rekin.icm.edu.pl [192.168.1.132]) by gw.icm.edu.pl (8.11.6/8.11.6/rzm-3.9/icm) with ESMTP id g5IJBFE15192 for ; Tue, 18 Jun 2002 21:11:15 +0200 (CEST) Received: from burza.icm.edu.pl (burza.icm.edu.pl [192.168.1.198]) by rekin.icm.edu.pl (8.11.6/8.11.6/rzm-2.7.2/icm) with ESMTP id g5IJBDJ01634 for ; Tue, 18 Jun 2002 21:11:13 +0200 Received: from burza.icm.edu.pl (localhost [127.0.0.1]) by burza.icm.edu.pl (8.12.2/8.12.0/rzm-2.8zero0/icm) with ESMTP id g5IJBCTU026780 for ; Tue, 18 Jun 2002 21:11:13 +0200 (CEST) Received: (from rzm@localhost) by burza.icm.edu.pl (8.12.2/8.12.0/Submit) id g5IJBBuT026779 for netdev@oss.sgi.com; Tue, 18 Jun 2002 21:11:11 +0200 (CEST) Date: Tue, 18 Jun 2002 21:11:11 +0200 From: Rafal Maszkowski To: netdev@oss.sgi.com Subject: 2.2.20pre2: ipv6_route entries shifted Message-ID: <20020618211111.A28253@burza.icm.edu.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline User-Agent: Mutt/1.2.5i X-MIME-Autoconverted: from 8bit to quoted-printable by gw.icm.edu.pl id g5IJBFE15192 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g5IJ8SnC030456 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 4046 Lines: 48 On a 6BONE router (SparcStation 10) I typically have same 3000 /proc/;net/ipv6_route entries. Usually few tens of them miss 1 or 2 bytes at the beginning of lines, the total amount of all shifts may be about 70 bytes. The whole table read few times and grepped to show one of the tunnel interfaces is below. All readouts where done during few minutes, 3 readouts in the middle during some 20 seconds. fe8010000700150000000000000000 7e 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 0000028 c 00240001 supernet 3ffe8010000700150000000000000000 40 00000000000000000000000000000000 00 3ffe8010000700150000000000000002 00000400 00000000 00000 000 00000003 supernet 800000000000000000000000000000 0a 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 0000000 0 00240001 supernet ff000000000000000000000000000000 08 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000 000 00040001 supernet root@6bone-gw:~ftp/pub/ipv6/conf,0# cat /proc/net/ipv6_route | grep superne 3ffe8010000700150000000000000000 7e 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 0000028c 00240001 supernet 3ffe8010000700150000000000000000 40 00000000000000000000000000000000 00 3ffe8010000700150000000000000002 00000400 00000000 00000000 00000003 supernet fe800000000000000000000000000000 0a 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 000000000000000 00240001 supernet 000000000000000000000000000000 08 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00040001 supernet root@6bone-gw:~ftp/pub/ipv6/conf,0# cat /proc/net/ipv6_route | grep superne 3ffe8010000700150000000000000000 7e 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 0000028c 00240001 supernet 3ffe8010000700150000000000000000 40 00000000000000000000000000000000 00 3ffe8010000700150000000000000002 00000400 00000000 00000000 00000003 supernet fe800000000000000000000000000000 0a 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 000000000000000 00240001 supernet ff000000000000000000000000000000 08 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00040001 supernet root@6bone-gw:~ftp/pub/ipv6/conf,0# cat /proc/net/ipv6_route | grep superne 3ffe8010000700150000000000000000 7e 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 0000028c 00240001 supernet 3ffe8010000700150000000000000000 40 00000000000000000000000000000000 00 3ffe8010000700150000000000000002 00000400 00000000 00000000 00000003 supernet fe800000000000000000000000000000 0a 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 000000000000000 00240001 supernet 000000000000000000000000000000 08 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00040001 supernet root@6bone-gw:~ftp/pub/ipv6/conf,0# cat /proc/net/ipv6_route | grep superne 3ffe8010000700150000000000000000 7e 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 0000028c 00240001 supernet 3ffe8010000700150000000000000000 40 00000000000000000000000000000000 00 3ffe8010000700150000000000000002 00000400 00000000 00000000 00000003 supernet fe800000000000000000000000000000 0a 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00240001 supernet ff000000000000000000000000000000 08 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00040001 supernet I do not see so fast changes in the routing itself so I suspect is only some readout error - maybe in /proc. I do not exclude possibility of memory errors but in this case I would expect the errors to happen not only at the beginnings Of lines. R. -- Avec mes souvenirs/J'ai allumé le feu Mes chagrins, mes plaisirs/Je n'ai plus besoin d'eux! From owner-netdev@oss.sgi.com Wed Jun 19 02:26:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5J9QNnC013252 for ; Wed, 19 Jun 2002 02:26:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5J9QN2j013251 for netdev-outgoing; Wed, 19 Jun 2002 02:26:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from wms1.pannongsm.hu (wms1.pannongsm.hu [193.225.153.26]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5J9QFnC013243 for ; Wed, 19 Jun 2002 02:26:16 -0700 Received: from localhost.localdomain ([193.225.155.77]) by wms1.pannongsm.hu (InterMail vK.4.04.00.00 201-232-137 license 657ede9314b8fb83c6cc010c4145b728) with ESMTP id <20020619092908.MUMU6155.wms1@localhost.localdomain>; Wed, 19 Jun 2002 11:29:08 +0200 Subject: Re: net/ipv6/exthdrs.c From: Kis-Szabo Andras To: kuznet@ms2.inr.ac.ru Cc: Netdev In-Reply-To: <1024435482.1332.10.camel@arwen> References: <200206181903.XAA13710@sex.inr.ac.ru> <1024435482.1332.10.camel@arwen> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1024478965.882.2.camel@arwen> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.0.5 Date: 19 Jun 2002 11:30:39 +0200 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1778 Lines: 44 Hello, > > Is there any plan to add the ESP header to the ipv6_ext_hdr() function (as a > > known header)? > No, ESP is not a normal extension header, it terminates parse. > So, ipv6_skip_headers cannot skip it. The same behaviour as in NONE, but the NONE is listed and the ESP is not. (But it is not a problem to me, I just asked something :) ) > BTW the same is with netfilter. I do not see how are you going to use it. :-) The ESP belongs to the headers, it is a member of a possible chain. - header match - i had to search for the ESP, too - ESP match - it has a public SPI value, which can be used in rules - general iteration, skipped together with the NONE. It terminates the header chain, but the existance of the ESP header and its SPI value are usefull information. > > (It requires changes in this file and in the icmp.c at the first round.) > I am afraid this will simply break the function. Yes, i am afraid You're right. :( Adding the ESP to the headers will break the icmp code. :( > This may be right even not depending on this issue. Goals are different: > the function in exthdrs.c does the best efforts to guess what protocol > is, the function in netfilter should be paranoid. I added a similar function (exactly the same but with the ESP) to decide about the nexthdr value and a new header parser/evaluator with strict size/pointer checks. Last week one of our user sent a direct request to eliminate the duplicated functions - so He pushed me to send the original question to this forum. Thanks for the answers, I 'wrote up them'. Regards, kisza -- Andras Kis-Szabo Security Development, Design and Audit -------------------------/ Zorp, NetFilter and IPv6 kisza@SecurityAudit.hu /-----Member of the BUTE-MIS-SEARCHlab------> From owner-netdev@oss.sgi.com Wed Jun 19 02:40:24 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5J9eOnC013792 for ; Wed, 19 Jun 2002 02:40:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5J9eOVb013790 for netdev-outgoing; Wed, 19 Jun 2002 02:40:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sex.inr.ac.ru (sex.inr.ac.ru [193.233.7.165]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5J9eInC013776 for ; Wed, 19 Jun 2002 02:40:19 -0700 Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id NAA15342; Wed, 19 Jun 2002 13:42:20 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200206190942.NAA15342@sex.inr.ac.ru> Subject: Re: net/ipv6/exthdrs.c To: kisza@pannongsm.hu (Kis-Szabo Andras) Date: Wed, 19 Jun 2002 13:42:20 +0400 (MSD) Cc: netdev@oss.sgi.com In-Reply-To: <1024478965.882.2.camel@arwen> from "Kis-Szabo Andras" at Jun 19, 2 11:30:39 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 874 Lines: 30 Hello! > The same behaviour as in NONE, Yes, this is equivalent. And the function behaves exactly as you expect then. :-) > The ESP belongs to the headers, it is a member of a possible chain. Like UDP, TCP (and NONE as you noticed). Not like headers mentioned in ipv6_ext_hdr(). > - header match - i had to search for the ESP, too > - ESP match - it has a public SPI value, which can be used in rules > - general iteration, skipped together with the NONE. > It terminates the header chain, but the existance of the ESP header and > its SPI value are usefull information. Hey, we spoke about _skip_. For all items mentioned by you ESP is considered like UDP&TCP, not like extension header! > about the nexthdr value and a new header parser/evaluator with strict > size/pointer checks. I feel you make something wrong yet. Or I do not understand something. Alexey From owner-netdev@oss.sgi.com Wed Jun 19 08:51:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5JFpHnC029088 for ; Wed, 19 Jun 2002 08:51:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JFpHIp029087 for netdev-outgoing; Wed, 19 Jun 2002 08:51:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from brinquendo.conectiva.com.br (3-135.ctame701-2.telepar.net.br [200.181.171.135]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5JFpEnC029084 for ; Wed, 19 Jun 2002 08:51:15 -0700 Received: by brinquendo.conectiva.com.br (Postfix, from userid 500) id 8AC011966C; Wed, 19 Jun 2002 06:54:15 -0300 (BRT) Date: Wed, 19 Jun 2002 06:54:15 -0300 From: Arnaldo Carvalho de Melo To: "David S. Miller" Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: [PATCH][2.5.22] OOPS in tcp_v6_get_port Message-ID: <20020619095415.GC5663@conectiva.com.br> References: <20020617.143319.54623892.davem@redhat.com> <200206180943.NAA12296@sex.inr.ac.ru> <20020618.025811.36457258.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020618.025811.36457258.davem@redhat.com> User-Agent: Mutt/1.4i X-Url: http://advogato.org/person/acme Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 343 Lines: 12 Em Tue, Jun 18, 2002 at 02:58:11AM -0700, David S. Miller escreveu: > From: kuznet@ms2.inr.ac.ru > Date: Tue, 18 Jun 2002 13:43:21 +0400 (MSD) > > I am afraid you speak about different bug. > > It is different bug, indeed. The oops looked very similar, it > tricked me :-) I'll be looking at this while in Ottawa 8) - Arnaldo From owner-netdev@oss.sgi.com Wed Jun 19 09:51:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5JGpUnC031232 for ; Wed, 19 Jun 2002 09:51:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JGpUGA031231 for netdev-outgoing; Wed, 19 Jun 2002 09:51:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from el-zoido.localnet (port-213-20-224-71.reverse.qdsl-home.de [213.20.224.71]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5JGpPnC031227 for ; Wed, 19 Jun 2002 09:51:26 -0700 Received: from trash.net (kaber@ws.localnet [192.168.0.100]) by el-zoido.localnet (8.11.6/linuxconf) with ESMTP id g5JGsGd06434 for ; Wed, 19 Jun 2002 18:54:16 +0200 Message-ID: <3D10B6FE.1050602@trash.net> Date: Wed, 19 Jun 2002 18:53:18 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020412 Debian/0.9.9-6 X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: kfree_skb: unnecessary check ? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 652 Lines: 28 Hi everyone. In skbuff.h one sees: static inline void kfree_skb(struct sk_buff *skb) { if (atomic_read(&skb->users) == 1 || atomic_dec_and_test(&skb->users)) __kfree_skb(skb); } Is atomic_dec_and_test really necessary ? atomic_dec_and_test only returns true if its argument has hit zero, so it was 1 before. If atomic_dec is only a bit cheaper than atomic_dec_and_test (which i guess it is), wouldn't it make more sense to use something like this: static inline void kfree_skb(struct sk_buff *skb) { if (atomic_read(&skb->users) == 1) __kfree(skb); else atomic_dec(&skb->users); } Bye, Patrick From owner-netdev@oss.sgi.com Wed Jun 19 11:38:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5JIc1nC016764 for ; Wed, 19 Jun 2002 11:38:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JIc1Dm016763 for netdev-outgoing; Wed, 19 Jun 2002 11:38:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5JIb2nC016758 for ; Wed, 19 Jun 2002 11:37:02 -0700 Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5JIdsS18510 for ; Wed, 19 Jun 2002 14:39:54 -0400 (EDT) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NFR0WPX8; Wed, 19 Jun 2002 14:39:53 -0400 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MSYXHWXM; Wed, 19 Jun 2002 14:39:54 -0400 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 91845540C for ; Wed, 19 Jun 2002 14:39:53 -0400 (EDT) Message-ID: <3D10CFF9.B4072FEA@nortelnetworks.com> Date: Wed, 19 Jun 2002 14:39:53 -0400 From: Chris Friesen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: how to report network device errors to userspace? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 572 Lines: 15 I'm curious about the proper way for a network device driver to report faults to userspace. The network devices don't seem to have /dev entries as a rule, so that makes it difficult to use select/poll to alert a user app. I haven't been able to find a standard interface for this--does nobody care about this kind of thing? -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com From owner-netdev@oss.sgi.com Wed Jun 19 12:48:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5JJmAnC020208 for ; Wed, 19 Jun 2002 12:48:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JJm9DP020207 for netdev-outgoing; Wed, 19 Jun 2002 12:48:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from loewe.cosy.sbg.ac.at (loewe.cosy.sbg.ac.at [141.201.2.12]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5JJm5nC020204 for ; Wed, 19 Jun 2002 12:48:05 -0700 Received: from mausmaki.cosy.sbg.ac.at (mausmaki.cosy.sbg.ac.at [141.201.2.18]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with ESMTP id VAA06959; Wed, 19 Jun 2002 21:51:02 +0200 (MET DST) Date: Wed, 19 Jun 2002 21:51:02 +0200 (MET DST) From: "Thomas 'Dent' Mirlacher" To: Patrick McHardy cc: netdev@oss.sgi.com Subject: Re: kfree_skb: unnecessary check ? In-Reply-To: <3D10B6FE.1050602@trash.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 385 Lines: 20 patrick, --snip/snip > static inline void kfree_skb(struct sk_buff *skb) > { - if (atomic_read(&skb->users) == 1) + if (likely(atomic_read(&skb->users) == 1)) > __kfree(skb); > else > atomic_dec(&skb->users); > } is even faster for the likely case by 1 2 jmps (gcc3.1). (well, is it the likely case?) tm -- in some way i do, and in some way i don't. From owner-netdev@oss.sgi.com Wed Jun 19 13:19:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5JKJ9nC020664 for ; Wed, 19 Jun 2002 13:19:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JKJ9ST020663 for netdev-outgoing; Wed, 19 Jun 2002 13:19:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from localhost.localdomain (dsl093-058-082.blt1.dsl.speakeasy.net [66.93.58.82]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5JKJ5nC020660 for ; Wed, 19 Jun 2002 13:19:05 -0700 Received: from localhost (becker@localhost) by localhost.localdomain (8.9.3/8.8.7) with ESMTP id QAA04164; Wed, 19 Jun 2002 16:21:48 -0400 Date: Wed, 19 Jun 2002 16:21:48 -0400 (EDT) From: Donald Becker X-X-Sender: To: Chris Friesen cc: Subject: Re: how to report network device errors to userspace? In-Reply-To: <3D10CFF9.B4072FEA@nortelnetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 737 Lines: 23 On Wed, 19 Jun 2002, Chris Friesen wrote: > I'm curious about the proper way for a network device driver to report > faults to userspace. What type of fault? Errors are counted in /proc/net/dev. > I haven't been able to find a standard interface for this--does nobody care > about this kind of thing? People very much care. There are sufficient reporting mechanisms for most errors -- it's much more consistent, orthogonal and thorough than other device types. Compare /proc/net/dev with the errors reported for disks, serial, USB, keyboard... -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From owner-netdev@oss.sgi.com Wed Jun 19 13:44:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5JKiEnC021751 for ; Wed, 19 Jun 2002 13:44:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JKiEfC021750 for netdev-outgoing; Wed, 19 Jun 2002 13:44:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5JKi9nC021747 for ; Wed, 19 Jun 2002 13:44:09 -0700 Received: from sex.inr.ac.ru (sex.inr.ac.ru [193.233.7.165]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id NAA03720 for ; Wed, 19 Jun 2002 13:47:19 -0700 (PDT) mail_from (kuznet@ms2.inr.ac.ru) From: kuznet@ms2.inr.ac.ru Received: (from kuznet@localhost) by sex.inr.ac.ru (8.6.13/ANK) id AAA17502; Thu, 20 Jun 2002 00:26:30 +0400 Message-Id: <200206192026.AAA17502@sex.inr.ac.ru> Subject: Re: kfree_skb: unnecessary check ? To: kaber@trash.NET (Patrick McHardy) Date: Thu, 20 Jun 2002 00:26:30 +0400 (MSD) Cc: netdev@oss.sgi.com In-Reply-To: <3D10B6FE.1050602@trash.net> from "Patrick McHardy" at Jun 19, 2 09:15:00 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 818 Lines: 34 Hello! > Is atomic_dec_and_test really necessary ? atomic_dec_and_test only > returns true if its argument has hit zero, so it was 1 before. > If atomic_dec is only a bit cheaper than atomic_dec_and_test (which i > guess it is), wouldn't it make more sense to use something like this: Does the prefix "atomic" not scare you? :-) > static inline void kfree_skb(struct sk_buff *skb) > { > if (atomic_read(&skb->users) == 1) > __kfree(skb); > else > atomic_dec(&skb->users); > } else if (atomic_dec_and_test(&skb->users)) __kfree_skb(skb); If you still do not understand think why it does not look like: static inline void kfree_skb(struct sk_buff *skb) { int users = skb->users; if (users == 1) __kfree(skb); else skb->users = users - 1; } Alexey From owner-netdev@oss.sgi.com Wed Jun 19 14:17:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5JLHQnC022115 for ; Wed, 19 Jun 2002 14:17:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JLHQsj022114 for netdev-outgoing; Wed, 19 Jun 2002 14:17:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5JLGOnC022106 for ; Wed, 19 Jun 2002 14:16:24 -0700 Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5JLJGT01682; Wed, 19 Jun 2002 17:19:16 -0400 (EDT) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KTYBWJWY; Wed, 19 Jun 2002 17:19:15 -0400 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MSYXHXMA; Wed, 19 Jun 2002 17:19:15 -0400 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id C5362540C; Wed, 19 Jun 2002 17:19:14 -0400 (EDT) Message-ID: <3D10F552.C05ADD53@nortelnetworks.com> Date: Wed, 19 Jun 2002 17:19:14 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Chris Friesen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Donald Becker Cc: netdev@oss.sgi.com Subject: Re: how to report network device errors to userspace? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1873 Lines: 45 Donald Becker wrote: > > On Wed, 19 Jun 2002, Chris Friesen wrote: > > > I'm curious about the proper way for a network device driver to report > > faults to userspace. > > What type of fault? I'm looking for asynchronous notification of events such as loss of ethernet carrier or SONET LOS/LOF/LCD/RDI/AIS. When the driver figures out (whether interrupt or poll-based) that it's lost connectivity it then somehow notifies a userspace app that something has happened, so the userspace app can deal with it. Currently the way we are doing it for ethernet is that the userspace app calls a device ioctl() with SIOCGMIIREG multiple times per second, but it would be nice to have the driver notify us asynchronously. > People very much care. There are sufficient reporting mechanisms for > most errors -- it's much more consistent, orthogonal and thorough than > other device types. Compare /proc/net/dev with the errors reported for > disks, serial, USB, keyboard... Is it possible to select() on an entry in /proc/net becoming readable? Is reading from /proc/net and converting from ASCII faster than doing an ioctl() to the driver and getting binary data? Basically, I want a userspace app to be notified somehow by the kernel that a link that I've expressed interest in has lost physical connectivity, and I want to get that information as fast as possible after the event. I've hacked a SONET driver to allow a userspace app to register its pid, which then gets sent SIGUSR1 on critical events to tell it to use ioctl() to get the actual information, but this is not very clean nor is it scalable. Thanks, Chris -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com From owner-netdev@oss.sgi.com Wed Jun 19 14:34:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5JLYInC022334 for ; Wed, 19 Jun 2002 14:34:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JLYIPr022333 for netdev-outgoing; Wed, 19 Jun 2002 14:34:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5JLYBnC022327 for ; Wed, 19 Jun 2002 14:34:12 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id C8CB214C68; Wed, 19 Jun 2002 23:37:05 +0200 (MEST) Date: Wed, 19 Jun 2002 23:36:59 +0200 From: Andi Kleen To: Chris Friesen Cc: Donald Becker , netdev@oss.sgi.com Subject: Re: how to report network device errors to userspace? Message-ID: <20020619233659.A7368@wotan.suse.de> References: <3D10F552.C05ADD53@nortelnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D10F552.C05ADD53@nortelnetworks.com> User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1621 Lines: 42 On Wed, Jun 19, 2002 at 05:19:14PM -0400, Chris Friesen wrote: > Donald Becker wrote: > > > > On Wed, 19 Jun 2002, Chris Friesen wrote: > > > > > I'm curious about the proper way for a network device driver to report > > > faults to userspace. > > > > What type of fault? > > I'm looking for asynchronous notification of events such as loss of ethernet > carrier or SONET LOS/LOF/LCD/RDI/AIS. When the driver figures out (whether > interrupt or poll-based) that it's lost connectivity it then somehow notifies a > userspace app that something has happened, so the userspace app can deal with > it. > > Currently the way we are doing it for ethernet is that the userspace app calls a > device ioctl() with SIOCGMIIREG multiple times per second, but it would be nice > to have the driver notify us asynchronously. I would suggest sending a netlink message from the driver. That's really what netlink was designed for. > > > People very much care. There are sufficient reporting mechanisms for > > most errors -- it's much more consistent, orthogonal and thorough than > > other device types. Compare /proc/net/dev with the errors reported for > > disks, serial, USB, keyboard... > > Is it possible to select() on an entry in /proc/net becoming readable? Is Yes, but it's very ugly to implement and not recommended. > reading from /proc/net and converting from ASCII faster than doing an ioctl() to > the driver and getting binary data? It's quite slow. When you plan to do this often better go with some binary interface (experience has shown for other statistics that /proc has a huge overhead) -Andi From owner-netdev@oss.sgi.com Wed Jun 19 14:42:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5JLgDnC022513 for ; Wed, 19 Jun 2002 14:42:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JLgDk7022512 for netdev-outgoing; Wed, 19 Jun 2002 14:42:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5JLfEnC022508 for ; Wed, 19 Jun 2002 14:41:14 -0700 Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5JLi6S19229; Wed, 19 Jun 2002 17:44:06 -0400 (EDT) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NFR0WTDV; Wed, 19 Jun 2002 17:44:06 -0400 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MSYXHXNT; Wed, 19 Jun 2002 17:44:06 -0400 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 9F9BC540C; Wed, 19 Jun 2002 17:44:05 -0400 (EDT) Message-ID: <3D10FB25.667421CB@nortelnetworks.com> Date: Wed, 19 Jun 2002 17:44:05 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Chris Friesen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Andi Kleen Cc: Donald Becker , netdev@oss.sgi.com Subject: Re: how to report network device errors to userspace? References: <3D10F552.C05ADD53@nortelnetworks.com> <20020619233659.A7368@wotan.suse.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 460 Lines: 14 Andi Kleen wrote: > I would suggest sending a netlink message from the driver. That's really > what netlink was designed for. Can you point me to a driver that's done this cleanly as an example to follow? Chris -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com From owner-netdev@oss.sgi.com Wed Jun 19 14:43:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5JLh3nC022540 for ; Wed, 19 Jun 2002 14:43:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JLh3RP022539 for netdev-outgoing; Wed, 19 Jun 2002 14:43:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from trained-monkey.org (IDENT:root@trained-monkey.org [209.217.122.11]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5JLgxnC022536 for ; Wed, 19 Jun 2002 14:43:00 -0700 Received: (from jes@localhost) by trained-monkey.org (8.11.6/8.9.3) id g5JLjui20222; Wed, 19 Jun 2002 17:45:56 -0400 To: Andi Kleen Cc: Chris Friesen , Donald Becker , netdev@oss.sgi.com Subject: Re: how to report network device errors to userspace? References: <3D10F552.C05ADD53@nortelnetworks.com> <20020619233659.A7368@wotan.suse.de> From: Jes Sorensen Date: 19 Jun 2002 17:45:55 -0400 In-Reply-To: Andi Kleen's message of "Wed, 19 Jun 2002 23:36:59 +0200" Message-ID: X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 739 Lines: 20 >>>>> "Andi" == Andi Kleen writes: Andi> On Wed, Jun 19, 2002 at 05:19:14PM -0400, Chris Friesen wrote: >> Currently the way we are doing it for ethernet is that the >> userspace app calls a device ioctl() with SIOCGMIIREG multiple >> times per second, but it would be nice to have the driver notify us >> asynchronously. Andi> I would suggest sending a netlink message from the driver. Andi> That's really what netlink was designed for. Hmmm, the broader issue here is that we should aim for a generic interface - if netlink is the way, maybe it would be worth documenting it and moving towards getting it into more/all drivers. I have had this question from other sides as well - hadn't thought of netlink. Cheers, Jes From owner-netdev@oss.sgi.com Wed Jun 19 14:48:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5JLmbnC022736 for ; Wed, 19 Jun 2002 14:48:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JLmaid022735 for netdev-outgoing; Wed, 19 Jun 2002 14:48:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5JLlbnC022729 for ; Wed, 19 Jun 2002 14:47:37 -0700 Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5JLoTT02997; Wed, 19 Jun 2002 17:50:29 -0400 (EDT) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NFR0WTGN; Wed, 19 Jun 2002 17:50:29 -0400 Received: from pcard0ks.ca.nortel.com ([47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MSYXHXPD; Wed, 19 Jun 2002 17:50:29 -0400 Received: from nortelnetworks.com (localhost.localdomain [127.0.0.1]) by pcard0ks.ca.nortel.com (Postfix) with ESMTP id 74980540C; Wed, 19 Jun 2002 17:50:28 -0400 (EDT) Message-ID: <3D10FCA4.4CDD78E9@nortelnetworks.com> Date: Wed, 19 Jun 2002 17:50:28 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Chris Friesen X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jes Sorensen Cc: Andi Kleen , Donald Becker , netdev@oss.sgi.com Subject: Re: how to report network device errors to userspace? References: <3D10F552.C05ADD53@nortelnetworks.com> <20020619233659.A7368@wotan.suse.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 651 Lines: 19 Jes Sorensen wrote: > Hmmm, the broader issue here is that we should aim for a generic > interface - if netlink is the way, maybe it would be worth documenting > it and moving towards getting it into more/all drivers. I agree with this. Also, if we're going to make it generic, lets plan on using it for stuff other than just ethernet--I'd like to have it available for atm/sonet cards as well. Chris -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com From owner-netdev@oss.sgi.com Wed Jun 19 14:51:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5JLpMnC022850 for ; Wed, 19 Jun 2002 14:51:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JLpMaq022849 for netdev-outgoing; Wed, 19 Jun 2002 14:51:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5JLpJnC022846 for ; Wed, 19 Jun 2002 14:51:20 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 4E86E14C69; Wed, 19 Jun 2002 23:54:14 +0200 (MEST) Date: Wed, 19 Jun 2002 23:54:06 +0200 From: Andi Kleen To: Chris Friesen Cc: Andi Kleen , Donald Becker , netdev@oss.sgi.com Subject: Re: how to report network device errors to userspace? Message-ID: <20020619235406.A11706@wotan.suse.de> References: <3D10F552.C05ADD53@nortelnetworks.com> <20020619233659.A7368@wotan.suse.de> <3D10FB25.667421CB@nortelnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D10FB25.667421CB@nortelnetworks.com> User-Agent: Mutt/1.3.22.1i Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 370 Lines: 12 On Wed, Jun 19, 2002 at 05:44:05PM -0400, Chris Friesen wrote: > Andi Kleen wrote: > > > I would suggest sending a netlink message from the driver. That's really > > what netlink was designed for. > > Can you point me to a driver that's done this cleanly as an example to follow? Not exactly a driver, but you can e.g. look at the ip_queue netfilter module. -Andi From owner-netdev@oss.sgi.com Wed Jun 19 19:42:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5K2gqnC027371 for ; Wed, 19 Jun 2002 19:42:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5K2gqTg027370 for netdev-outgoing; Wed, 19 Jun 2002 19:42:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from blackbird.intercode.com.au (blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5K2gknC027367 for ; Wed, 19 Jun 2002 19:42:47 -0700 Received: from localhost (jmorris@localhost) by blackbird.intercode.com.au (8.9.3/8.9.3) with ESMTP id MAA32400; Thu, 20 Jun 2002 12:44:49 +1000 Date: Thu, 20 Jun 2002 12:44:49 +1000 (EST) From: James Morris To: Andi Kleen cc: Chris Friesen , Donald Becker , Subject: Re: how to report network device errors to userspace? In-Reply-To: <20020619235406.A11706@wotan.suse.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 745 Lines: 27 On Wed, 19 Jun 2002, Andi Kleen wrote: > On Wed, Jun 19, 2002 at 05:44:05PM -0400, Chris Friesen wrote: > > Andi Kleen wrote: > > > > > I would suggest sending a netlink message from the driver. That's really > > > what netlink was designed for. > > > > Can you point me to a driver that's done this cleanly as an example to follow? > > Not exactly a driver, but you can e.g. look at the ip_queue netfilter > module. > It's not a very clean example at this stage, unfortunately, as it contains some fairly ugly logic for maintaining unicast sessions. If you don't specifically need unicast Netlink (which I don't think you do), try also looking at the tcpdiag & ctnetlink code. - James -- James Morris From owner-netdev@oss.sgi.com Wed Jun 19 19:54:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5K2sEnC027529 for ; Wed, 19 Jun 2002 19:54:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5K2sEAa027528 for netdev-outgoing; Wed, 19 Jun 2002 19:54:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5K2s7nC027524 for ; Wed, 19 Jun 2002 19:54:07 -0700 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id WAA13707; Wed, 19 Jun 2002 22:56:54 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g5K2oxQ29023; Wed, 19 Jun 2002 22:51:00 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Wed, 19 Jun 2002 22:50:59 -0400 (EDT) From: jamal To: James Morris cc: Andi Kleen , Chris Friesen , Donald Becker , , Stefan Rompf Subject: Re: how to report network device errors to userspace? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1165 Lines: 43 Before someone reinvents the wheel, did anyone actually bother following the discussion that happened here on netdev: http://marc.theaimsgroup.com/?t=101751064400001&r=1&w=2 If Stefan Rompf hasnt disapeared or is buried in work somewhere, all pieces are already in place. thats what the device netcarrier state is for. cheers, jamal On Thu, 20 Jun 2002, James Morris wrote: > On Wed, 19 Jun 2002, Andi Kleen wrote: > > > On Wed, Jun 19, 2002 at 05:44:05PM -0400, Chris Friesen wrote: > > > Andi Kleen wrote: > > > > > > > I would suggest sending a netlink message from the driver. That's really > > > > what netlink was designed for. > > > > > > Can you point me to a driver that's done this cleanly as an example to follow? > > > > Not exactly a driver, but you can e.g. look at the ip_queue netfilter > > module. > > > > It's not a very clean example at this stage, unfortunately, as it contains > some fairly ugly logic for maintaining unicast sessions. > > If you don't specifically need unicast Netlink (which I don't think you > do), try also looking at the tcpdiag & ctnetlink code. > > > - James > -- > James Morris > > > From owner-netdev@oss.sgi.com Thu Jun 20 00:59:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5K7xgnC030701 for ; Thu, 20 Jun 2002 00:59:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5K7xgIk030700 for netdev-outgoing; Thu, 20 Jun 2002 00:59:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5K7xcnC030697 for ; Thu, 20 Jun 2002 00:59:39 -0700 Received: from dea.linux-mips.net (c-180-196-136.ka.dial.de.ignite.net [62.180.196.136]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id BAA04251 for ; Thu, 20 Jun 2002 01:02:44 -0700 (PDT) mail_from (ralf@linux-mips.net) Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5K7d4U03935 for netdev@oss.sgi.com; Thu, 20 Jun 2002 09:39:04 +0200 Received: from zwkxm.zw.com.cn ([61.151.251.195]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5K1nunC026864 for ; Wed, 19 Jun 2002 18:49:58 -0700 Received: from public ([202.109.116.253]) by zwkxm.zw.com.cn with Microsoft SMTPSVC(5.0.2195.3779); Thu, 20 Jun 2002 09:53:37 +0800 Message-ID: <002301c21479$92ce7f00$c9001eac@public> From: "=?gb2312?B?zsDH5Q==?=" To: Subject: A question on "Scheduling in interrupt". Date: Sat, 15 Jun 2002 22:33:09 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01C214BC.A0B63CA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-OriginalArrivalTime: 20 Jun 2002 01:53:37.0882 (UTC) FILETIME=[4B643BA0:01C217FD] Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 8445 Lines: 202 This is a multi-part message in MIME format. ------=_NextPart_000_0020_01C214BC.A0B63CA0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Dear Networking Teak, I am a system engineer in a Chinese software development company, and = currently I am implementing IPSec on Linux version 2.2.16. Generally = speaking, what I am doing is adding internet key exchange and IPsec = processing functions into the Linux ip_queue_xmit, ip_build_xmit and = ip_local_deliver procedures. After I have built up a new sk_buff = variable, I send it off using my own function send_skbuff(), this is = where the problem occurs. Following is the complete copy of the culprit: void send_skbuff(struct sk_buff *skb) { struct rtable *rt; struct iphdr *iph; iph =3D skb->nh.iph; if(ip_route_output(&rt, iph->daddr, iph->saddr, IPTOS_LOWDELAY, 0)) goto drop; skb->dst =3D dst_clone(&rt->u.dst); skb->priority =3D TC_PRIO_FILLER; if (skb_cloned(skb)) skb =3D skb_copy(skb, GFP_ATOMIC); else skb =3D skb_clone(skb, GFP_ATOMIC); if (skb->len > rt->u.dst.pmtu) goto fragment; skb->dst->output(skb); return; fragment: ip_fragment(skb, skb->dst->output); return; drop: kfree_skb(skb);=20 } All functions within the above procedure are kernel supplied and = irrelevant to the problem, so I will skip its explanation. I use the kgdb to debug my codes. Everything worked fine until I had = crossed the skb->dst->output(skb) statement and hit upon return. Then, = when I typed =A1=B0next=A1=B1 on host machine, the system crashed with = =A1=B0Scheduling in interrupt!=A1=B1 appearing on target machine and the = following message on my host machine: Program received signal SIGSEGV, Segmentation fault. Schedule () at sched.c: 875 875 *(int *)0 =3D 0 Leery of some low level codes within the = =A1=B0skb->dst->output(skb)=A1=B1 provoked the crash, I step into that = statement which points to function ip_output. Alas, the system crashed = with the same reason upon the first statement of procedure ip_output, = and that statement does simple book keeping! The problem is patent: scheduling while within the interrupt processing, = the myth is how could it ever be scheduling within interrupt since I am = not doing anything within the interrupt context!? It is a well known = fact that within Linux there are three places to evoke scheduling, = either it is educed explicitly by the procedure itself, which won=A1=AFt = be within interrupt context as long as the caller is not within it; or = it can be elicited when the current process=A1=AFs time quantum is = exhausted or when a newly awakened process has a higher priority than = the current one, during these two situations, the system will mark the = need_resched flag, and the actual scheduling is performed when the = system returns from a interrupt, again within the context of the process = that is to be scheduled away. Therefore normally there is no chance to = be scheduling in interrupt. Where is the hole? The problem must be = caused by my codes, shouldn=A1=AFt it? By the way, I implemented the send_skbuff months ago, and together with = other codes they had been working fine. This scheduling in interrupt = problem only recently popped up when I was debugging error processing = for IPsec and the place it occurred is irrelevant to the error = processing. Any comments will be greatly appreciated. Regards, Lee Tong ------=_NextPart_000_0020_01C214BC.A0B63CA0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Dear Networking Teak,
 
I am a system engineer in a Chinese = software=20 development company, and currently I am implementing IPSec on Linux = version=20 2.2.16. Generally speaking, what I am doing is adding internet key = exchange and=20 IPsec processing functions into the Linux ip_queue_xmit, ip_build_xmit = and=20 ip_local_deliver procedures. After I have built up a new sk_buff = variable, I=20 send it off using my own function send_skbuff(), this is where the = problem=20 occurs. Following is the complete copy of the culprit:
 
void send_skbuff(struct sk_buff=20 *skb)
{
  struct rtable *rt;
  struct iphdr=20 *iph;
 
  iph =3D = skb->nh.iph;
 =20 if(ip_route_output(&rt, iph->daddr,=20 iph->saddr,
 IPTOS_LOWDELAY, 0))
    goto=20 drop;
  skb->dst =3D dst_clone(&rt->u.dst);
 =20 skb->priority =3D TC_PRIO_FILLER;
  if=20 (skb_cloned(skb))
    skb =3D skb_copy(skb,=20 GFP_ATOMIC);
  else
    skb =3D skb_clone(skb, = GFP_ATOMIC);
  if (skb->len >=20 rt->u.dst.pmtu)
    goto fragment;
 =20 skb->dst->output(skb);
  return;
fragment:
 =20 ip_fragment(skb, skb->dst->output);
  = return;
drop:
 =20 kfree_skb(skb);
}
 
All functions within the above = procedure are=20 kernel supplied and irrelevant to the problem, so I will skip its=20 explanation.
I use the kgdb to debug my codes. Everything worked fine = until I=20 had crossed the skb->dst->output(skb) statement and hit upon = return. Then,=20 when I typed “next” on host machine, the system crashed with = “Scheduling in interrupt!” appearing on target machine and = the=20 following message on my host machine:
 
Program received signal SIGSEGV, = Segmentation=20 fault.
Schedule () at sched.c: 875
875 *(int *)0 =3D = 0
 
Leery of some low level codes within = the=20 “skb->dst->output(skb)” provoked the crash, I step = into that=20 statement which points to function ip_output. Alas, the system crashed = with the=20 same reason upon the first statement of procedure ip_output, and that = statement=20 does simple book keeping!
The problem is patent: scheduling while = within the=20 interrupt processing, the myth is how could it ever be scheduling within = interrupt since I am not doing anything within the interrupt context!? = It is a=20 well known fact that within Linux there are three places to evoke = scheduling,=20 either it is educed explicitly by the procedure itself, which = won’t be=20 within interrupt context as long as the caller is not within it; or it = can be=20 elicited when the current process’s time quantum is exhausted or = when a=20 newly awakened process has a higher priority than the current one, = during these=20 two situations, the system will mark the need_resched flag, and the = actual=20 scheduling is performed when the system returns from a interrupt, again = within=20 the context of the process that is to be scheduled away. Therefore = normally=20 there is no chance to be scheduling in interrupt. Where is the hole? The = problem=20 must be caused by my codes, shouldn’t it?
By the way, I = implemented the=20 send_skbuff months ago, and together with other codes they had been = working=20 fine. This scheduling in interrupt problem only recently popped up when = I was=20 debugging error processing for IPsec and the place it occurred is = irrelevant to=20 the error processing.
Any comments will be greatly = appreciated.
 
Regards,
 
Lee = Tong
------=_NextPart_000_0020_01C214BC.A0B63CA0-- From owner-netdev@oss.sgi.com Thu Jun 20 02:35:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5K9ZWnC002737 for ; Thu, 20 Jun 2002 02:35:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5K9ZWiR002736 for netdev-outgoing; Thu, 20 Jun 2002 02:35:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from www.linux.org.uk (parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5K9ZRnC002733 for ; Thu, 20 Jun 2002 02:35:28 -0700 Received: from adsl-33-178-32.asm.bellsouth.net ([67.33.178.32] helo=mandrakesoft.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 17KyOa-0004PT-00; Thu, 20 Jun 2002 10:38:28 +0100 Message-ID: <3D11A292.2060105@mandrakesoft.com> Date: Thu, 20 Jun 2002 05:38:26 -0400 From: Jeff Garzik Organization: MandrakeSoft User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/00200205 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: ethtool 1.6 released Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 848 Lines: 23 This is a feature release, with no bug fixes since version 1.5. It supports the new features in recent ethtool API changes: control of interrupt coalescing, and many diagnostic/debugging commands. Download from http://prdownloads.sourceforge.net/gkernel/ethtool-1.6.tar.gz NEWS file: Version 1.6 - June 20, 2002 * Feature: Support e1000 register dumps * Feature: Support RealTek RTL-8139C+ and RTL-8169 register dumps * Feature: Support coalescing config (ETHTOOL_[GS]COALESCE) * Feature: Support ring param config (ETHTOOL_[GS]RINGPARAM) * Feature: Support pause param config (ETHTOOL_[GS]PAUSEPARAM) * Feature: Support physical NIC identification (ETHTOOL_PHYS_ID) * Feature: Support NIC self-testing (ETHTOOL_TEST) * Feature: Support NIC checksum/scatter-gather enable/disable (ETHTOOL_[GS]RXCSUM, ETHTOOL_[GS]TXCSUM, ETHTOOL_[GS]SG) From owner-netdev@oss.sgi.com Thu Jun 20 02:55:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5K9tInC002942 for ; Thu, 20 Jun 2002 02:55:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5K9tIr0002941 for netdev-outgoing; Thu, 20 Jun 2002 02:55:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from loewe.cosy.sbg.ac.at (loewe.cosy.sbg.ac.at [141.201.2.12]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5K9tFnC002938 for ; Thu, 20 Jun 2002 02:55:15 -0700 Received: from mausmaki.cosy.sbg.ac.at (mausmaki.cosy.sbg.ac.at [141.201.2.18]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with ESMTP id LAA01708 for ; Thu, 20 Jun 2002 11:58:16 +0200 (MET DST) Date: Thu, 20 Jun 2002 11:58:16 +0200 (MET DST) From: "Thomas 'Dent' Mirlacher" To: netdev@oss.sgi.com Subject: netdev_boot_setup quesion Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 140 Lines: 11 hi list, i stumbled across netdev_boot_setup - is it still used by someone? thanks, tm -- in some way i do, and in some way i don't. From owner-netdev@oss.sgi.com Thu Jun 20 03:34:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5KAYXnC003791 for ; Thu, 20 Jun 2002 03:34:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5KAYXp4003790 for netdev-outgoing; Thu, 20 Jun 2002 03:34:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from el-zoido.localnet (port-212-202-184-18.reverse.qdsl-home.de [212.202.184.18]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5KAYQnC003777 for ; Thu, 20 Jun 2002 03:34:27 -0700 Received: from trash.net (kaber@ws.localnet [192.168.0.100]) by el-zoido.localnet (8.11.6/linuxconf) with ESMTP id g5JLXId16966; Wed, 19 Jun 2002 23:33:18 +0200 Message-ID: <3D10F863.4070204@trash.net> Date: Wed, 19 Jun 2002 23:32:19 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020412 Debian/0.9.9-6 X-Accept-Language: en MIME-Version: 1.0 To: kuznet@ms2.inr.ac.ru CC: netdev@oss.sgi.com Subject: Re: kfree_skb: unnecessary check ? References: <200206192026.AAA17502@sex.inr.ac.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 908 Lines: 43 kuznet@ms2.inr.ac.ru wrote: >Hello! > >>Is atomic_dec_and_test really necessary ? atomic_dec_and_test only >>returns true if its argument has hit zero, so it was 1 before. >>If atomic_dec is only a bit cheaper than atomic_dec_and_test (which i >>guess it is), wouldn't it make more sense to use something like this: >> > >Does the prefix "atomic" not scare you? :-) > > >>static inline void kfree_skb(struct sk_buff *skb) >>{ >> if (atomic_read(&skb->users) == 1) >> __kfree(skb); >> else >> atomic_dec(&skb->users); >>} >> > > else if (atomic_dec_and_test(&skb->users)) > __kfree_skb(skb); > >If you still do not understand think why it does not look like: > >static inline void kfree_skb(struct sk_buff *skb) >{ > int users = skb->users; > if (users == 1) > __kfree(skb); > else > skb->users = users - 1; >} > >Alexey > Hehe got it :) Thanks Patrick From owner-netdev@oss.sgi.com Thu Jun 20 10:34:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5KHYnnC031940 for ; Thu, 20 Jun 2002 10:34:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5KHYnMQ031939 for netdev-outgoing; Thu, 20 Jun 2002 10:34:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5KHYSnC031935 for ; Thu, 20 Jun 2002 10:34:28 -0700 Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA00801 for ; Thu, 20 Jun 2002 10:37:45 -0700 (PDT) mail_from (george@mvista.com) Received: from data.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA23550; Thu, 20 Jun 2002 10:20:18 -0700 Received: from mvista.com (IDENT:george@localhost [127.0.0.1]) by data.mvista.com (8.9.3/8.9.3) with ESMTP id KAA05076; Thu, 20 Jun 2002 10:19:43 -0700 Message-ID: <3D120EAE.5A0D365E@mvista.com> Date: Thu, 20 Jun 2002 10:19:42 -0700 From: george anzinger Organization: Monta Vista Software X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12-20b i686) X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" , kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-net@vger.kernel.org, ak@muc.de, pekkas@netcore.fi, "Cress, Andrew R" Subject: Re: Network oops References: <200205202125.BAA03545@sex.inr.ac.ru> <3D0390E2.1B80ADEE@mvista.com> <20020609.213150.32126725.davem@redhat.com> <3D042F8F.72764243@mvista.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 7875 Lines: 169 We need help from someone who knows the network code. I have tried to give all the relevant information below. The machine that last failed can still be examined with kgdb to answer any further questions. We are working with a 2.4.17 kernel with all the latest preempt patches as well as the high-res-timres patch (which, by the way has the proposed TIMER_BH conversion to softirq code). Other patches are applied but, when removed, do not affect the below described behavior. The system is an SMP (2) processor: <4>CPU0: Intel(R) Pentium(R) III CPU family 1266MHz stepping 01 A break point placed in deliver_to_old_ones() is never hit. Failure rate under heavy network stress (4 machines each measuring network performance with all 4 machines in the test) occurs very seldom. The last failure took 32 hours, the prior one 22 hours. Failure appears to occur because a call is made to a bogus address that is pulled from an skb. Here is a back trace of the latest failure: Program received signal SIGEMT, Emulation trap. 0x00b24d18 in ?? () at af_packet.c:1891 (gdb) bt #0 0x00b24d18 in ?? () at af_packet.c:1891 #1 0xc0267751 in tcp_v4_destroy_sock (sk=0xc7164260) at /usr/src/linux-2.4.17-CLT/include/net/tcp.h:1673 #2 0xc02566f1 in tcp_destroy_sock (sk=0xc7164260) at tcp.c:1800 #3 0xc025731a in tcp_close (sk=0xc7164260, timeout=0) at tcp.c:1971 #4 0xc0274f67 in inet_release (sock=0xc2c94160) at af_inet.c:465 #5 0xc02304a2 in sock_release (sock=0xc2c94160) at socket.c:489 #6 0xc0230a50 in sock_close (inode=0xc2c94040, filp=0xc51297e0) at socket.c:724 #7 0xc014d833 in fput (file=0xc51297e0) at file_table.c:113 #8 0xc014bfe3 in filp_close (filp=0xc51297e0, id=0xc2eb6d60) at open.c:838 #9 0xc014c0b2 in sys_close (fd=4) at open.c:862 #10 0xc010782b in system_call () at af_packet.c:1891 #11 0x40043507 in ?? () at af_packet.c:1891 ( kgdb caught this in: 0xc0119b3d is in do_page_fault (fault.c:329). 324 * terminate things with extreme prejudice. 325 */ 326 #ifdef CONFIG_KGDB 327 if (!user_mode(regs)){ 328 kgdb_handle_exception(14,SIGBUS, error_code, regs); 329 return; 330 } 331 #endif 332 333 bust_spinlocks(1); ( In both failures we found this in the log buffer just prior to the failure: <5>\n<4>KERNEL: assertion ((int)tcp_packets_in_flight(tp) >= 0) failed at tcp_input.c(956):tcp_sacktag_write_queue\n On the assumption that preemption is the root cause of this problem we have instrumented the preemption code to keep track of the last 100 preemptions. What follows is an edited log of these preemptions. Each entry consists of two words of time (sec, usec) followed by the address (hex and symbolic) and the pid of the process. Preemptions clearly unrelated to the network code have been removed. Most of these were in idle or sched_yield. 0xc0368e60 : 0x3d101941 0xc9868 0xc025f4bb 0x15aa 0xc0368e80 : 0x3d101941 0xec247 0xc025d821 0x15aa 0xc0368ea0 : 0x3d101942 0xc1f6 0xc0167ee0 0x15ae 0xc0368ec0 : 0x3d101942 0x24440 0xc025d821 0x15aa 0xc0368ee0 : 0x3d101942 0x26eae 0xc025d821 0x15a9 0xc0368f00 : 0x3d101942 0x2a4b4 0xc025d821 0x15aa 0xc0368f20 : 0x3d101942 0x2c74a 0xc02558b1 0x15aa 0xc0368f40 : 0x3d101942 0x2d5b6 0xc0255741 0x15aa 0xc0368f60 : 0x3d101942 0x2e634 0xc02558b1 0x15a9 0xc0368f80 : 0x3d101942 0x2fcaa 0xc024db81 0x15aa 0xc0368fc0 : 0x3d101942 0x30c4f 0xc02558b1 0x15a6 0xc0368fe0 : 0x3d101942 0x33603 0xc02558b1 0x15a6 0xc0369000 : 0x3d101942 0xc5137 0xc011d1ec 0x15a8 0xc0369060 : 0x3d101944 0x6f2e4 0xc025561b 0x15a8 0xc0369120 : 0x3d101948 0xae22f 0xc024dc28 0x15b2 0xc0369140 : 0x3d101949 0xbe01 0xc02558b1 0x15b2 0xc03691a0 : 0x3d10194b 0xbd567 0xc025d821 0x15b3 0xc0369250 : 0x3d10194b 0xbde39 0xc01054df 0x0 Each of these is pinned to source below: (gdb) (gdb)l* l* tcp_transmit_skb+747 0xc01f4a83 is in tcp_transmit_skb (/usr/src/cvs/hhl-kernel-cambell/linux_test/include/net/tcp.h:1422). 1417 TCPOLEN_TIMESTAMP); 1418 *ptr++ = htonl(tstamp); 1419 *ptr++ = htonl(tp->ts_recent); 1420 } 1421 if (tp->eff_sacks) { 1422 struct tcp_sack_block *sp = tp->dsack ? tp->duplicate_sack : tp->selective_acks; 1423 int this_sack; 1424 1425 *ptr++ = __constant_htonl((TCPOPT_NOP << 24) | 1426 (TCPOPT_NOP << 16) | (gdb)l * tcp_copy_to_iovec+129 0xc01f2eed is in tcp_copy_to_iovec (tcp_input.c:3157). 3152 int chunk = skb->len - hlen; 3153 int err; 3154 3155 local_bh_enable(); 3156 if (skb->ip_summed==CHECKSUM_UNNECESSARY) 3157 err = skb_copy_datagram_iovec(skb, hlen, tp->ucopy.iov, chunk); 3158 else 3159 err = skb_copy_and_csum_datagram_iovec(skb, hlen, tp->ucopy.iov); 3160 3161 if (!err) { (gdb) l *tcp_prequeue_process+305 0xc01ebba5 is in tcp_recvmsg (tcp.c:1400). 1395 int err; 1396 int target; /* Read at least this many bytes */ 1397 long timeo; 1398 struct task_struct *user_recv = NULL; 1399 1400 lock_sock(sk); 1401 1402 TCP_CHECK_TIMER(sk); 1403 1404 err = -ENOTCONN; (gdb) l* tcp_data_wait+705 0xc01ebb49 is in tcp_prequeue_process (tcp.c:1376). 1371 while ((skb = __skb_dequeue(&tp->ucopy.prequeue)) != NULL) 1372 sk->backlog_rcv(sk, skb); 1373 local_bh_enable(); 1374 1375 /* Clear memory counter. */ 1376 tp->ucopy.memory = 0; 1377 } 1378 1379 /* 1380 * This routine copies from a sock struct into the user buffer. (gdb) l *tcp_data_wait+411 0xc01eba23 is in tcp_data_wait (tcp.c:1354). 1349 release_sock(sk); 1350 1351 if (skb_queue_empty(&sk->receive_queue)) 1352 timeo = schedule_timeout(timeo); 1353 1354 lock_sock(sk); 1355 clear_bit(SOCK_ASYNC_WAITDATA, &sk->socket->flags); 1356 1357 remove_wait_queue(sk->sleep, &wait); 1358 __set_current_state(TASK_RUNNING); (gdb) (gdb) l *ip_queue_xmit+24 0xc024dc28 is in ip_queue_xmit (ip_output.c:351). 346 struct iphdr *iph; 347 348 /* Skip all of this if the packet is already routed, 349 * f.e. by something like SCTP. 350 */ 351 rt = (struct rtable *) skb->dst; 352 if (rt != NULL) 353 goto packet_routed; 354 355 /* Make sure we can route this packet. */ (gdb) (gdb) l * ip_output+401 0xc01e55d9 is in ip_queue_xmit (ip_output.c:344). 339 } 340 341 int ip_queue_xmit(struct sk_buff *skb) 342 { 343 struct sock *sk = skb->sk; 344 struct ip_options *opt = sk->protinfo.af_inet.opt; 345 struct rtable *rt; 346 struct iphdr *iph; 347 348 /* Skip all of this if the packet is already routed, Any help would be greatly appreciated. We also can probe the system to answer any further questions. As said above, we are assuming this is related to preemption, however, that assumption may be bad. Thanks -- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Real time sched: http://sourceforge.net/projects/rtsched/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml From owner-netdev@oss.sgi.com Thu Jun 20 15:20:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5KMKNnC012511 for ; Thu, 20 Jun 2002 15:20:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5KMKN2T012510 for netdev-outgoing; Thu, 20 Jun 2002 15:20:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5KMK8nC012507 for ; Thu, 20 Jun 2002 15:20:08 -0700 Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA01817 for ; Thu, 20 Jun 2002 15:23:25 -0700 (PDT) mail_from (george@mvista.com) Received: from data.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id PAA03649; Thu, 20 Jun 2002 15:05:38 -0700 Received: from mvista.com (IDENT:george@localhost [127.0.0.1]) by data.mvista.com (8.9.3/8.9.3) with ESMTP id PAA05695; Thu, 20 Jun 2002 15:05:18 -0700 Message-ID: <3D12519E.F81FE36A@mvista.com> Date: Thu, 20 Jun 2002 15:05:18 -0700 From: george anzinger Organization: Monta Vista Software X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12-20b i686) X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" , kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-net@vger.kernel.org, ak@muc.de, pekkas@netcore.fi, "Cress, Andrew R" , mark Orvek , Tim Anderson , mhuth@mvista.com, dfarnsworth@mvista.com, minyard@mvista.com Subject: Net work bug. More info. Content-Type: multipart/mixed; boundary="------------894BCFCAFA669B25CFEC7187" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 7330 Lines: 114 This is a multi-part message in MIME format. --------------894BCFCAFA669B25CFEC7187 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit We have been looking more closely at the failure. Attached is a gdb log... As turns out, the failure is actually one level lower than tcp_v4_destroy_sock() in __kfree_skb(). It attempts to call a destructor which has a bogus address. The failing instruction is the call *(reg). tcp_writequeue_purge(sk)-> tcp_free_skb(sk, skb)-> __kfree_skb() The attached log has the sk and the "bad" skb as rendered by gdb. -- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Real time sched: http://sourceforge.net/projects/rtsched/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml --------------894BCFCAFA669B25CFEC7187 Content-Type: application/x-zip-compressed; name="jun19info.ZIP" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="jun19info.ZIP" UEsDBBQAAAAIANeL1CzYhm30qREAAE87AAANAAAAanVuMTlpbmZvLnR4dMU7a2/dNpbfDfg/ EG4GtVM7EfW+aeJB0ckMig2y2KCL+VJAoCTK1vpeSdHDdmr4v+85JEWRlBy3KRZ7iyb3Hp4X z5uicnx0elXmZ2Tqjo++o4R494Xnx0kSUVI3ZCy67DbMSj6MffslG9rihpwON+8AK6Fx6Mfe 2fERgQ8byetp6F8PffF6XzfT/YX/KnxFk4ufP/z6um6K/VTy1w0fXwPHV9dvaJwEx0f4JzE+ WXZT9Zxnw00OQvKzH4+Vch15OdwcH72IyTvyULKy7OFL6IWh5yUxjc9JX9xmg4aD9rHvhek5 Kbu2HxEWeUl0TprpAD+8c9Q5b6emhJ3dZnUlgKTh94jr3cP3ruv57fwjrwHTWBXkCFuwisSL OeMgchjZyAGWkO9/Y9+fk99Z1/ESABQAnkcBNCitKPVoKLhV7FDvvwDIh73waUAGnsD3EP96 Gsv2rgFgIIDB94hWFQ1yeShgJyPHrfuPgtse3QQLw/xF/e09nhPg3Q9yv3efjbX5bwo4Ixtu sn09CO7aO9oA0vU72KuxfQl6fHwUzsgntGmaBCnIGfacd4bpymHMClZc89m+CHDVgBBMfBoj uwM/ZGwPC/ZmPbnZnhe8vuXZ54lPyPHB0TMPV3oi6POeN9IMs2QZyNp6FLdy97RsctfXoyFW ki/C46KM89gzhUcQscz3toQbQpFR+zW5uCbEYlRd+CEN0h1NqQyktr9jfalpYTWiMY0ScMNG fgg0NtYtqhPuYsFjaErpPxpQL/GNHaCvOLODuWwbK1qRw9Rf1Q2UATuMbyAM2k7uXAMB60pu zWSgCo6F2bQZxIwMZA3M+5aVBROhanHIh7IeDhZuyfPpyoJApI6Qr4dutYGBZ7Z/lw1jBqG7 BptVOwF2wToEB2gzYX8Z8XKTY33g0uvXbLjmjSwBMcYnq/vZwDkrbvYt6vlwLW095w2BxKz3 EgBxUIDzEPkrqcP7vu2fDlFMhsBf5YcAPRuisEHFxgtpkhSAOXZZVzdVi9isyqDU4zfsIbgT 3meSZ+Cfz7kGgsus2rMrYbUkCYMI/lMFvRF6+mGQ0DTEtBmwDCsgpHHkebHmhGtTw3AtStId LEaSYDjsJZBG8EciWWuvg/3TiPpYhS8uLn790nHytufj1DeXZGxJ0TYjdDN+TtqefLaWPk/1 CCS6aoAs5WBKkziOPRDFpOUg5kuIACtegNwO5ZkRGAVwu9bBz9H8IuMXGBtb6SIUDPGn402p hOGtY24PSZIN/Cob6t8VCC1xGND0YHPsDUXbfREK99wJGvlxQicuVqGDoGdDR36gjLX9F7UB 6DhEJUDd6mKjGD1KT97tqRUPpuvvGjRNDEtQrw7sPruD/tzeLbDuME5Z0bY3tXARxI6mBxPo fkRDLIsCslcREmIRh43bQbyQFyybe34oXBOK7jz2rBkO9TgIcbhAE7HQ9sBFhoPu5jMvYfVs uO6nRhhsqbK8AtGsKHhnlTpRLtqqsoRow/SjqDGQCYdSuCmQ3zKwEJoSY2Acb1m//IAQwbFg SaKZWS+Cjfog9pyYQaE/HajCxyGTkRhG6L9qnH+G2igKgg3LdOEwjNc9H65Rui89Xki30uVX Jmce2/lyQfkrjqCEGARQrksZZBq0JH+SpJioM7Mlj/SS4ckMl9FUD/NsZE2MukmaQc7vuxo2 ZXEcpjxb4NhT2YiFKwhCD0pREqcGg2pqCtWf5WjuwxhB3mJRlQ1KKHX5iCGyx26wUnIzgR2F iaWPq+DCYa3phoJxqBQ0NbpcrAIWztoqE3nw1NgW0lVbEqDPbvaRrSJDoPsMHS/qqi7I0qPE MAq1ONONtUj8NEmYFU6H4Srr2JWeThVIJpmqmjIuozScf08YT+vSJF2kU2oHp4QdREA3Qf8v 13Cov/UCX3GTXStr7dJwN8AkwF3ogJa3YX+1xQ3szmiciyQsv0IH8s6erTbAM6+mbdiVQ4Hz IdvjLA+zRc6HFbtxuGXYzCndBTDhLIaRi7zoidHRwVwZHg7UnOWQ6MWlGnh+GMYR9VI546nW KM4nbLtX8wrijLmjYDl1+xqmap4puocHkNHPpRW7STM72TNa4sD3HFIJ9q9YfpXunDirZp5/ FfHb2ODJQ/TUpdKGXqrmKaN2i6SYmUhHqoJvjPLTYcNurLyVJhdNWFvlS5NhDa6dgOBFoyfH Bdr1NUy8hjpBoDnt28HsRqgAJNs8N8EZ3GxfOKXXV9c6F915c+5l5iAZ7hIYXScwEjTY/kYe axRA4RPZ9yQPOCYtTsEfqrxicd4YGRHj0Jab+STG307SosXuWL06U6OzsSnwJmu7uQ3MDORo ocuxqHwmLFvOHvPR19BRs1lyeJk8F1jdjLd7CZRHIt8iliPql+Zz1t7yvtqL+Q21hoNFz+5C 3EtV7+VR+GHuRb546ABHHeEFyQ1+ZUNbKUdiKVyOVZ4cEFdAETr1OE+kWCdnZ+EheS9OeJZD 8AjUFi3uKBbAGIGc90UvZo6Hri6NDU7iV+jv4KCd+DsYUq4ciHx4AvtmckAiaoLHycunYRKm QRzKcUUdN5wVodJ8BBOH6KmAwbVt5XSN7Qpa49TUOP7pyUA9GJDrJdREOZajpw+Nnhd6aJoD xyO1fCChv5hPY1Q04hMf+Zwphu4G0xzGI1lCUTdrz9/5ifvI6a82Kvl5YtbBYGnHa64P3Eqq +H5VZGPP5wSY+YFB91AL1jt2Zw8Eof8zd7umZgauteuv6As+qxtuTXPjKMIO21yr2lSBY4ou ibBLneTkuuzxISx5t64cB9iy4LV0dADt29bu8tAsb2WOYakEG+EDUGJmr4jlIAl2VJ62ynoo XLZAw+8lD/g1x52py+INuW95qCBG9IIhoHjMAf0oT7+bE+9fmXb/yKQbeKWadO2yJ8bxuTEo bUZoklw+EcLvk/qBiK3eoacmj7kPqBgUx8usuGaNmkpBeBAUHghHYpizK4i4Gz51lwIfyTNM 1y8Ldpma2LjI8j2X+GpKBVNr9hHNY+uYIVYv5+IKPbbn6in2rE5uCjBxJJWqtRmUNG3AGEwo heAlQ4trageqdM2YSQizG3mLSZApGRLh8lHdEcxXBfic/PjoOw9vMjwv98OSpniT8fe/k9Mz vKbQMfWqeEPTHT0+wj/RRY/LdcNrRl6+4EN3fPTTOPIDJBJUGTiu4CmcN2AmRq54A8f4gnRt jQXhlUUsaV8kUn+/KiiPPZv96W1bl2crISP4UZQ6KMMDaSuQBLPyhZJCYACeuCFLCUpBkGBI Xp5tSLxHiSZ4+f5GZIr0YRhWAXlr3ML8QGl0OTPZk5cLmmAxk9QDWtigwzuifKoqMHEQeGeg b+BHZOtTV+S0brK6/3x6doa5EvjxJuL8gS7djDen//H+08fs3z99+vjLx3+Rk3+zvoF54g1Z NIA0vWZ9eXz0y6f/In/rfmtOzpF58lXm8+fj+1+zn3/68OH9J3EPhRdRgZ9uoj7i0m5zCUgv LudAbfv5SgsssuIQiAAk39UVJA/5+T8//vOXf2WgxT9/+fDr+0+I4Fs0TZVBjECjximmm8ZT IaupilFKkNdq3+GAVuHv0KIGZPUwq25qQXtOPv73hw/nxDv7kZDXL0mx56xRV1kvXzspdr9E +DfEkUEUaqKg8mnup2uUVKOIx4vBBkqhUcTvXbhCSUzt5N2mLjrGzeYP8TrYBbYKdnUrOjx5 Mfonb0BDTAwaxyJ6HsR1qGe76eJyfqT+Sj5Pf+U+IPxRkFGXzLwjungnIxHCkOOzX0lixROS 2DdHP2wSPXdbi5vCpUfxNRJ/inTGSIJaqS6FRKFCC0JL668UB1nvhSFfDjfYPyUApnSoJAgD t+DdBvKT1rIy0t32xg5Uh6gHBsdMQ/3jo39M0Kux2A4w4UJf7KEEw0ELbLJ0fYPgzVL+sK0a K5dvlDr4iAf++hvPOwOZOmmh0A/tLRHIQ3fuUDiJFCgKzb6sDeTQRg5t9t59eorcz0BGeW+Q JTZZskVW3gsyUxpzNuNJuhFyQqnmUhQOhS8p/ocTKUiiMXfPmJaaB3d4qE1qZUO9x8LY4861 vNqktqOF7DvIqYX8QuCVUJM9g8Yxoq88hbd0am+UVgVk+FvZwow97Ry7+EreVPrMwHJ2Hih7 dzCpiy0wcwuVg0wdZDMAmOcg+45Nt+Nmw082mb8Ejqkbix261Akcdu9SpE5ge5uBkztODneG kZkTrqHapDiOlRwORzJ22P2ZQeTYPIz/kGU2FHHIis2Uyp0giqKnUupbD8ha0s6RlGxatHIU otQ0aZ47TOxtQp5U8OF4Y2T7s3ACLlZJzOBISXQdtCiclIxdRyjXOWlfRA7ZzjFoce9SuMWQ bhqGu6XMSw3DFI51k8DRNvC0utYuHa6J2uVwvVcGjVwKJ88TN9IKL0x3gLgpr3TMk7rxtsrE 0jFPuh03XzdP6ZgndZVeariZHaXDdOc7NdxCLh3kYLuGx0YN506Q7dI/XsO5mymeFLhZcHnq IssEeKas8NwlS2wZZiBvueCNZS0TuXSRpUvUzl8uFWuh2Zrx/8AmqtglS+1NmOG2VX+UjL30 onc+6/VXS2Ll2sCX+4GjkNyPv1m0I89z6eSG7kEk2UqiyHPnC9XKzV3JJDANHnk7lywxDY4h bRezyFsNS/6GoNQVRCOXbG11wF2RuREXxRtk1HPpfDeQ4mCLbqWm7w6gyZYZ/RVdsJoFpR17 3v0Ox452mH02vEHS2iR1VVX1VvvanXmjwLVlSk2nCYqN7IoCN9dT7ex82VzMVnROQ6A7ukWX u3Shu7NdtGHMeKVn6DjB93SI3S10SezSRZ5Llz5VPcyIjhw1fUrtqmYhhy6yb1a1OfHxyaJG ghPkpcFh53JIbC0r+Sm2GlYUuXO975nUSIJR1hkU3KXw7eKYm8iVixyoOB6/vRq+hxHMOgiX cDR2H25iPX+xkw839aMbIZN8wLsmhuf2nIzX8OWODSTneE8o3sQBSMXq/dTzNwvTU/ewf2Yy fgEOereBs35whC+KAzaS4KtiT1yp2Fc+6sUzajyxN57V64f36oE9dCs/isXbNpIbvlNArgXV tQBUgcdYiq9DTg5A8qqLQ+di1lcbsK52YZLB0N27uD27syDk7U9l2fNhMGF4rw2eFe+9D+p1 nEZoPguilZB7Gxs/WW8v3i+/pDqzbICYYvGnK5EcmHifmeP1W6PuPPCFMpeXgJncJGDFr1Ru LKIg4YF6U6bIASYvuTDEO87GAfwmromGy3NygtdRuGz+z0/Ov07j+/Fv+RZSYjM+md9aDPw0 Cf0gTeLlTma1QopB/ZMEkmVTo95VW67Min3b2C99Iq/uZszU/fRyGV13GfA6OK+IGpfage9H 0Np3cbr8KwB1ObVcagb+o3WvHfr4Jg3E/qS4ULzNnZ+pEfGCuZ+mcSpfFNQvVvHcg1odmz6c QbYXtXFmsjCmLpkAbZDpVxL+nDQuLy7v8yBnXmgSKYhDo2+jWnlnLC+Vlosnu/CZr41j/THK 3MvNOqf+oQAWLXwdwngRDs4JLA/N2iX//UKRGiUMDnhllHpLJdN3hqtiZtSx0PfCZGfUMaeK Ff4u516iX11woEYVM2BXK5gqebqULci6ii2gOftnCCRUfgIqyiI1szKposKsVwtMFy0Nmqnv XVRbKHTsk/cnT1QqiRJyp1jNYHJyYpQkvI/fKkShrhfIRRYE+dKxUSG8JwrDkte6MBhv931r YfC+Ug+oXQ5SqxZ4ViWgcZymdhUo6I7FWLlPRO3UaS7hDOAn50sWC2gcpgg181TAq0Ji27n4 iNn3f38vBT9O35EcdgVEZ2uC/6dbKoP2z6qcaJVpmq9XF23hFOyH+iZ5QUk9a8/+FopWKlmv afkbdMWzrHfPS98tJhG/87VTdovfPJjq4orO7y0b5qYxXdt797yKTKsYsN1aNnPUK4s1Smqi 4AS0RimeRcm951HC51FSW91qrW6+6ALWTALKpDWhVA38Bz+l3tqOxfN+LJ43VGH6MYk9fOor XxXh4t3tH6JgQ7RWdy2ztGxGq3Ats9RqWe79X1BLAQIUCxQAAAAIANeL1CzYhm30qREAAE87 AAANAAAAAAAAAAEAIAAAAAAAAABqdW4xOWluZm8udHh0UEsFBgAAAAABAAEAOwAAANQRAAAA AA== --------------894BCFCAFA669B25CFEC7187-- From owner-netdev@oss.sgi.com Thu Jun 20 17:41:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5L0fAnC014378 for ; Thu, 20 Jun 2002 17:41:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5L0fAPp014377 for netdev-outgoing; Thu, 20 Jun 2002 17:41:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5L0f8nC014374 for ; Thu, 20 Jun 2002 17:41:08 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id RAA06066; Thu, 20 Jun 2002 17:38:06 -0700 Date: Thu, 20 Jun 2002 17:38:05 -0700 (PDT) Message-Id: <20020620.173805.55219901.davem@redhat.com> To: george@mvista.com Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-net@vger.kernel.org, ak@muc.de, pekkas@netcore.fi, andrew.r.cress@intel.com Subject: Re: Network oops From: "David S. Miller" In-Reply-To: <3D120EAE.5A0D365E@mvista.com> References: <20020609.213150.32126725.davem@redhat.com> <3D042F8F.72764243@mvista.com> <3D120EAE.5A0D365E@mvista.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 275 Lines: 7 I don't understand, you've completely turned the preemption model of the kernel upside down and you want _US_ to debug this for you? This is a lot of work, work I personally don't have time for. It requires a full audit of the networking in the new preemption environment. From owner-netdev@oss.sgi.com Fri Jun 21 07:14:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5LEEvnC007423 for ; Fri, 21 Jun 2002 07:14:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5LEEv4J007422 for netdev-outgoing; Fri, 21 Jun 2002 07:14:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5LEEqnC007416 for ; Fri, 21 Jun 2002 07:14:52 -0700 Received: from data.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id HAA21186; Fri, 21 Jun 2002 07:16:49 -0700 Received: from mvista.com (IDENT:george@localhost [127.0.0.1]) by data.mvista.com (8.9.3/8.9.3) with ESMTP id HAA06842; Fri, 21 Jun 2002 07:16:25 -0700 Message-ID: <3D133538.60B6810C@mvista.com> Date: Fri, 21 Jun 2002 07:16:24 -0700 From: george anzinger Organization: Monta Vista Software X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12-20b i686) X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-net@vger.kernel.org, ak@muc.de, pekkas@netcore.fi, andrew.r.cress@intel.com Subject: Re: Network oops References: <20020609.213150.32126725.davem@redhat.com> <3D042F8F.72764243@mvista.com> <3D120EAE.5A0D365E@mvista.com> <20020620.173805.55219901.davem@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1504 Lines: 26 "David S. Miller" wrote: > > I don't understand, you've completely turned the preemption model of > the kernel upside down and you want _US_ to debug this for you? You could look at it this way :) On the other hand, I prefer to think of the linux community as a group of folks working on making one of the best OSs on the planet even better. Its adoption by more and more companies attests to its place in the world. We who work on it, IMHO, should cooperate with each other in our efforts to make the system even better. Sure we will disagree about some of the things others are doing and thus the need for some central control of the system. For this we are indebted to Linus. And we may not have time to spend working on the system when others would most like us to, but that is the nature of life and we should respect others in this regard. So while I would very much like your help, I understand that you may be busy with other things at this time and not have the time. Still, I must ask, just as others ask of me. > > This is a lot of work, work I personally don't have time for. I can understand and accept that. > It requires a full audit of the networking in the new preemption > environment. Any pointers on what to look for would be welcome. -- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Real time sched: http://sourceforge.net/projects/rtsched/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml From owner-netdev@oss.sgi.com Fri Jun 21 07:20:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5LEKSnC007562 for ; Fri, 21 Jun 2002 07:20:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5LEKSYI007561 for netdev-outgoing; Fri, 21 Jun 2002 07:20:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5LEKOnC007558 for ; Fri, 21 Jun 2002 07:20:25 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id HAA09532; Fri, 21 Jun 2002 07:17:21 -0700 Date: Fri, 21 Jun 2002 07:17:20 -0700 (PDT) Message-Id: <20020621.071720.07439917.davem@redhat.com> To: george@mvista.com Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-net@vger.kernel.org, ak@muc.de, pekkas@netcore.fi, andrew.r.cress@intel.com Subject: Re: Network oops From: "David S. Miller" In-Reply-To: <3D133538.60B6810C@mvista.com> References: <3D120EAE.5A0D365E@mvista.com> <20020620.173805.55219901.davem@redhat.com> <3D133538.60B6810C@mvista.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 732 Lines: 21 From: george anzinger Date: Fri, 21 Jun 2002 07:16:24 -0700 [ BTW please start using newlines in your emails, instead of 1,000 character monstrosities lacking them. Thanks ] On the other hand, I prefer to think of the linux community as a group of folks working on making one of the best OSs on the planet even better. Right, and I don't think CONFIG_PREEMPT makes the planet better. In fact, now that you mention it, I think CONFIG_PREEMPT is a pile of crap. > It requires a full audit of the networking in the new preemption > environment. Any pointers on what to look for would be welcome. And you go right back to asking me to do the work for you. What is wrong with you? From owner-netdev@oss.sgi.com Fri Jun 21 08:11:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5LFAxnC008559 for ; Fri, 21 Jun 2002 08:10:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5LFAxIk008558 for netdev-outgoing; Fri, 21 Jun 2002 08:10:59 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5LFAsnC008555 for ; Fri, 21 Jun 2002 08:10:54 -0700 Received: from data.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id IAA22792; Fri, 21 Jun 2002 08:12:49 -0700 Received: from mvista.com (IDENT:george@localhost [127.0.0.1]) by data.mvista.com (8.9.3/8.9.3) with ESMTP id IAA06943; Fri, 21 Jun 2002 08:12:29 -0700 Message-ID: <3D13425D.EA1EA546@mvista.com> Date: Fri, 21 Jun 2002 08:12:29 -0700 From: george anzinger Organization: Monta Vista Software X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12-20b i686) X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-net@vger.kernel.org, ak@muc.de, pekkas@netcore.fi, andrew.r.cress@intel.com Subject: Re: Network oops References: <3D120EAE.5A0D365E@mvista.com> <20020620.173805.55219901.davem@redhat.com> <3D133538.60B6810C@mvista.com> <20020621.071720.07439917.davem@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1227 Lines: 38 "David S. Miller" wrote: > > From: george anzinger > Date: Fri, 21 Jun 2002 07:16:24 -0700 > > [ BTW please start using newlines in your emails, instead of 1,000 > character monstrosities lacking them. Thanks ] Sure. I am trying to find something that works with patches as well as text. Still looking I guess. > > On the other hand, I prefer to think of the linux community as a > group of folks working on making one of the best OSs on the planet > even better. > > Right, and I don't think CONFIG_PREEMPT makes the planet better. > In fact, now that you mention it, I think CONFIG_PREEMPT is a pile > of crap. Can we agree to disagree :) > > > It requires a full audit of the networking in the new preemption > > environment. > > Any pointers on what to look for would be welcome. > > And you go right back to asking me to do the work for you. > What is wrong with you? I said they would be welcome, not that you have to reply... -- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Real time sched: http://sourceforge.net/projects/rtsched/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml From owner-netdev@oss.sgi.com Fri Jun 21 09:52:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5LGqinC010997 for ; Fri, 21 Jun 2002 09:52:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5LGqi97010996 for netdev-outgoing; Fri, 21 Jun 2002 09:52:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from loewe.cosy.sbg.ac.at (loewe.cosy.sbg.ac.at [141.201.2.12]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5LGqcnC010993 for ; Fri, 21 Jun 2002 09:52:38 -0700 Received: from mausmaki.cosy.sbg.ac.at (mausmaki.cosy.sbg.ac.at [141.201.2.18]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with ESMTP id SAA23020 for ; Fri, 21 Jun 2002 18:55:44 +0200 (MET DST) Date: Fri, 21 Jun 2002 18:55:44 +0200 (MET DST) From: "Thomas 'Dent' Mirlacher" To: netdev@oss.sgi.com Subject: dev->type oddities Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1132 Lines: 39 hi list, can someone please send a comment the stuff below? net_device->type: o holds the interface hardware type (according to netdevice.h) o is set to ARPHRD_* (which should be ARP hardware identifiers) o in the arp code there are a couple of places where the type gets mapped to the correct ARP hardware header type hmm, so the type doesn't specify the arp hardware type, it specifies the mac/datalink type. wouldn't it be cleaner to split dev->type into dev->datalink_type (or dev->mac_type) and dev->arp_type ? plus defining DLT_* or whatever defines for the mac/datalink type. this would cost an int per device, but would improve readability? and helps getting rid of the type to arp type mappings in the arp code. (plus userspace apps could also benefit - using datalink_type as we do right now, will keep libpcap and friends happy, and dhcp apps could use the arp type (so they can support new datalink types, which use an already known arp_type) without the need to add a switch for the new datalink type - 802.11 for example) any comments? thanks, tm -- in some way i do, and in some way i don't. From owner-netdev@oss.sgi.com Fri Jun 21 18:03:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5M137nC013526 for ; Fri, 21 Jun 2002 18:03:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5M137o2013525 for netdev-outgoing; Fri, 21 Jun 2002 18:03:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5M134nC013522 for ; Fri, 21 Jun 2002 18:03:04 -0700 Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA08218 for ; Fri, 21 Jun 2002 18:06:24 -0700 (PDT) mail_from (andi@firstfloor.org) Received: from fwd11.sul.t-online.de by mailout10.sul.t-online.com with smtp id 17LZBz-000509-00; Sat, 22 Jun 2002 02:55:55 +0200 Received: from averell.firstfloor.org (520003261363-0001@[217.82.100.212]) by fmrl11.sul.t-online.com with esmtp id 17LZBy-1NcG6iC; Sat, 22 Jun 2002 02:55:54 +0200 Received: by averell.firstfloor.org (Postfix on SuSE Linux 7.3 (i386), from userid 500) id 5EF20699B8; Sat, 22 Jun 2002 02:55:51 +0200 (CEST) Date: Sat, 22 Jun 2002 02:55:51 +0200 From: Andi Kleen To: george anzinger Cc: "David S. Miller" , kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-net@vger.kernel.org, ak@muc.de, pekkas@netcore.fi, andrew.r.cress@intel.com Subject: Re: Network oops Message-ID: <20020622025551.A1919@averell> References: <20020609.213150.32126725.davem@redhat.com> <3D042F8F.72764243@mvista.com> <3D120EAE.5A0D365E@mvista.com> <20020620.173805.55219901.davem@redhat.com> <3D133538.60B6810C@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D133538.60B6810C@mvista.com> User-Agent: Mutt/1.3.22.1i X-Sender: 520003261363-0001@t-dialin.net Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 216 Lines: 8 > > It requires a full audit of the networking in the new preemption > > environment. > > Any pointers on what to look for would be welcome. I would look at the driver, especially races in its skb handling. -Andi From owner-netdev@oss.sgi.com Sat Jun 22 07:06:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5ME6enC019486 for ; Sat, 22 Jun 2002 07:06:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5ME6d5J019485 for netdev-outgoing; Sat, 22 Jun 2002 07:06:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from 21cn.com ([61.140.60.248]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5ME6ZnC019482 for ; Sat, 22 Jun 2002 07:06:36 -0700 Received: from arpabox([211.80.41.107]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm573d149310; Sat, 22 Jun 2002 22:08:58 +0800 Date: Sat, 22 Jun 2002 22:9:19 +0800 From: "Laudney Ren" Reply-To: laudney@21cn.com To: netdev Subject: T/TCP patch Beta-1.0 for kernel 2.4.2 launched. X-mailer: Foxmail 4.1 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Message-ID: Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 386 Lines: 15 The release is at http://sourceforge.net/projects/ttcplinux You can obtain the source files by checking out the CVS repository: cvs -z3 -d:pserver:anonymous@cvs.ttcplinux.sourceforge.net:/cvsroot/ttcplinux co 2.4.2 or downloading the zip file: http://west.dl.sourceforge.net/sourceforge/ttcplinux/2.4.2-ttcp-beta-1.0.zip PS. You can find a detailed README.txt in the zip file. From owner-netdev@oss.sgi.com Sat Jun 22 07:07:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5ME7JnC019511 for ; Sat, 22 Jun 2002 07:07:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5ME7JQ9019510 for netdev-outgoing; Sat, 22 Jun 2002 07:07:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from 21cn.com ([61.140.60.248]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5ME7GnC019506 for ; Sat, 22 Jun 2002 07:07:16 -0700 Received: from arpabox([211.80.41.107]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm1363d14f22e; Sat, 22 Jun 2002 22:06:20 +0800 Date: Sat, 22 Jun 2002 22:10:0 +0800 From: "Laudney Ren" Reply-To: laudney@21cn.com To: netdev Subject: T/TCP patch Beta-1.0 for kernel 2.4.2 launched. X-mailer: Foxmail 4.1 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Message-ID: Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 385 Lines: 14 The release is at http://sourceforge.net/projects/ttcplinux You can obtain the source files by checking out the CVS repository: cvs -z3 -d:pserver:anonymous@cvs.ttcplinux.sourceforge.net:/cvsroot/ttcplinux co 2.4.2 or downloading the zip file: http://west.dl.sourceforge.net/sourceforge/ttcplinux/2.4.2-ttcp-beta-1.0.zip PS. You can find a detailed README.txt in the zip file. From owner-netdev@oss.sgi.com Sat Jun 22 18:39:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5N1d7nC025042 for ; Sat, 22 Jun 2002 18:39:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5N1d7rg025041 for netdev-outgoing; Sat, 22 Jun 2002 18:39:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5N1d1nC025038 for ; Sat, 22 Jun 2002 18:39:03 -0700 Received: from alan by the-village.bc.nu with local (Exim 3.33 #5) id 17LwjD-0003hT-00; Sun, 23 Jun 2002 03:03:47 +0100 Subject: Re: RFC: per-socket statistics on received/dropped packets To: ltd@cisco.com (Lincoln Dale) Date: Sun, 23 Jun 2002 03:03:47 +0100 (BST) Cc: vonbrand@inf.utfsm.cl (Horst von Brand), davem@redhat.com (David S. Miller), greearb@candelatech.com (Ben Greear), linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <5.1.0.14.2.20020612221925.0283fb18@mira-sjcm-3.cisco.com> from "Lincoln Dale" at Jun 12, 2002 10:28:15 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 426 Lines: 9 > i know of many many folk who use transaction logs from HTTP caches for > volume-based billing. > right now, those bills are anywhere between 10% to 25% incorrect. > > you call that "extremely limited"? It wouldnt help you anyway. Prove which frames were not due to the overloading and congestion/errors on your network which therefore the customer should not have a duty to pay. Account for bitstuffing on HDLC links... From owner-netdev@oss.sgi.com Sat Jun 22 19:03:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5N23wnC025316 for ; Sat, 22 Jun 2002 19:03:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5N23w2W025315 for netdev-outgoing; Sat, 22 Jun 2002 19:03:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5N23rnC025310 for ; Sat, 22 Jun 2002 19:03:53 -0700 Received: from mira-sjcm-3.cisco.com (IDENT:mirapoint@mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5N26Bdg024691; Sat, 22 Jun 2002 19:06:11 -0700 (PDT) Received: from ltd-t22.cisco.com (syd-vpn-client-194-19.cisco.com [10.64.194.19]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id AFG15441; Sat, 22 Jun 2002 19:07:42 -0700 (PDT) Message-Id: <5.1.0.14.2.20020623120148.0399aae8@mira-sjcm-3.cisco.com> X-Sender: ltd@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 23 Jun 2002 12:05:44 +1000 To: Alan Cox From: Lincoln Dale Subject: Re: RFC: per-socket statistics on received/dropped packets Cc: vonbrand@inf.utfsm.cl (Horst von Brand), davem@redhat.com (David S. Miller), greearb@candelatech.com (Ben Greear), linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: References: <5.1.0.14.2.20020612221925.0283fb18@mira-sjcm-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1234 Lines: 33 g'day Alan, At 03:03 AM 23/06/2002 +0100, you wrote: > > i know of many many folk who use transaction logs from HTTP caches for > > volume-based billing. > > right now, those bills are anywhere between 10% to 25% incorrect. > > > > you call that "extremely limited"? > >It wouldnt help you anyway. Prove which frames were not due to the >overloading and congestion/errors on your network which therefore the >customer should >not have a duty to pay. Account for bitstuffing on HDLC links... sure - but these are all Layer-8 (politics) and layer-9 (religion) issues. typically Service Providers on this side of the planet handle that side of things via SLAs internal to their own network. i.e. "we guarantee X% uptime, less than Y% packet-loss across our own core network as measured using XXYYZZ method". the fact that an IP packet may have a PPP header on it across one hop, a HDLC header across another, perhaps some MPLS labels across another, 802.1q-in-802.1q across another is generally immaterial. if you did want to get fancy and account for it, at least you have packet-counters on a per-socket basis from which to do that with. without per-socket accounting, you just don't have that anyway. cheers, lincoln. From owner-netdev@oss.sgi.com Mon Jun 24 04:36:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5OBaenC025978 for ; Mon, 24 Jun 2002 04:36:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OBadeK025977 for netdev-outgoing; Mon, 24 Jun 2002 04:36:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from brmx1.fl.icn.siemens.com (brmx1.fl.icn.siemens.com [12.147.96.32]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5OBaanC025974 for ; Mon, 24 Jun 2002 04:36:37 -0700 Received: from boca210a.boca.ssc.siemens.com (boca210a.boca.ssc.siemens.com [165.218.12.110]) by brmx1.fl.icn.siemens.com (8.9.3/8.9.3) with ESMTP id HAA03702 for ; Mon, 24 Jun 2002 07:39:55 -0400 (EDT) Received: by boca210a.boca.ssc.siemens.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Jun 2002 07:39:55 -0400 Message-ID: <180577A42806D61189D30008C7E632E8793946@boca213a.boca.ssc.siemens.com> From: "Bloch, Jack" To: "'netdev@oss.sgi.com'" Subject: IP stack question Date: Mon, 24 Jun 2002 07:39:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 733 Lines: 15 I am writing this e-mail at the recommendation of Alan Cox. I have an embedded system running on cPCI HW which has two physical Ethernet connections. This system is connected to an internal network and the IP addresses are not made public. I use the IP addresses 10.1.1.4 and 10.1.1.5 respectively. The two physical ports are connected to two separate LAN switches which are connected by an uplink. I want to periodically test this uplink cable. My plan to do this is to send a simple test message (much like a ping) from 10.1.1.4 to 10.1.1.5, however, the IP stack does not let me do this. Is there any specific reason why not? Jack Bloch Siemens Carrier Networks e-mail : jack.bloch@icn.siemens.com phone : (561) 923-6550 From owner-netdev@oss.sgi.com Mon Jun 24 06:37:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5ODbVnC028559 for ; Mon, 24 Jun 2002 06:37:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5ODbVNo028558 for netdev-outgoing; Mon, 24 Jun 2002 06:37:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5ODbQnC028555 for ; Mon, 24 Jun 2002 06:37:26 -0700 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id JAA00316; Mon, 24 Jun 2002 09:40:44 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g5ODYm312904; Mon, 24 Jun 2002 09:34:48 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 24 Jun 2002 09:34:47 -0400 (EDT) From: jamal To: "Bloch, Jack" cc: "'netdev@oss.sgi.com'" Subject: Re: IP stack question In-Reply-To: <180577A42806D61189D30008C7E632E8793946@boca213a.boca.ssc.siemens.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1211 Lines: 31 I tried to explain to you in private mail: Both 10.1.1.4 and 10.1.1.5 are recognized to be local addresses by the IP stack. It is legit that the stack limits the scope to just that i.e _local_ The only way to do what you want to do is bypass the IP stack. Use packet socket to write your test app. (which actually probably defetas the whole purpose of what you may be trying to do -- HA). cheers, jamal On Mon, 24 Jun 2002, Bloch, Jack wrote: > I am writing this e-mail at the recommendation of Alan Cox. I have an > embedded system running on cPCI HW which has two physical Ethernet > connections. This system is connected to an internal network and the IP > addresses are not made public. I use the IP addresses 10.1.1.4 and 10.1.1.5 > respectively. The two physical ports are connected to two separate LAN > switches which are connected by an uplink. I want to periodically test this > uplink cable. My plan to do this is to send a simple test message (much like > a ping) from 10.1.1.4 to 10.1.1.5, however, the IP stack does not let me do > this. Is there any specific reason why not? > > Jack Bloch > Siemens Carrier Networks > e-mail : jack.bloch@icn.siemens.com > phone : (561) 923-6550 > From owner-netdev@oss.sgi.com Mon Jun 24 10:45:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5OHjFnC003243 for ; Mon, 24 Jun 2002 10:45:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OHjFip003242 for netdev-outgoing; Mon, 24 Jun 2002 10:45:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from exalane.intransa.com ([66.89.142.11]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5OHjAnC003236 for ; Mon, 24 Jun 2002 10:45:10 -0700 Received: from candelatech.com ([172.30.6.114]) by exalane.intransa.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 24 Jun 2002 10:48:16 -0700 Message-ID: <3D175B5F.5050403@candelatech.com> Date: Mon, 24 Jun 2002 10:48:15 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jamal CC: "Bloch, Jack" , "'netdev@oss.sgi.com'" Subject: Re: IP stack question References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jun 2002 17:48:16.0992 (UTC) FILETIME=[520DCE00:01C21BA7] Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1064 Lines: 29 jamal wrote: > I tried to explain to you in private mail: > Both 10.1.1.4 and 10.1.1.5 are recognized to be local addresses > by the IP stack. It is legit that the stack limits the scope > to just that i.e _local_ > The only way to do what you want to do is bypass the IP stack. > Use packet socket to write your test app. > (which actually probably defetas the whole purpose of what you may > be trying to do -- HA). It would not defeat the purpose of detecting at least one bad network link of the two. I wonder if a ping -I eth1 255.255.255.255 would accomplish the goal as well? I would actually like to be able to force a machine to not do local routing as well, and force packets out over an interface even if the destination is a local IP, using source-based-routing, or something similar. There is no way to do this currently? Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From owner-netdev@oss.sgi.com Mon Jun 24 12:02:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5OJ2QnC004090 for ; Mon, 24 Jun 2002 12:02:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OJ2Qhh004089 for netdev-outgoing; Mon, 24 Jun 2002 12:02:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from cyberus.ca (mail.cyberus.ca [216.191.240.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5OJ2JnC004086 for ; Mon, 24 Jun 2002 12:02:20 -0700 Received: from shell.cyberus.ca (shell [216.191.240.114]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id PAA20708; Mon, 24 Jun 2002 15:05:24 -0400 (EDT) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.11.6+Sun/8.11.6) with ESMTP id g5OIxJH14131; Mon, 24 Jun 2002 14:59:27 -0400 (EDT) X-Authentication-Warning: shell.cyberus.ca: hadi owned process doing -bs Date: Mon, 24 Jun 2002 14:59:04 -0400 (EDT) From: jamal To: Ben Greear cc: "Bloch, Jack" , "'netdev@oss.sgi.com'" Subject: Re: IP stack question In-Reply-To: <3D175B5F.5050403@candelatech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1126 Lines: 37 On Mon, 24 Jun 2002, Ben Greear wrote: > It would not defeat the purpose of detecting at least one bad network > link of the two. > Unless i misunderstood: He seems to be trying to do a loopback test from one of his interfaces to the network and back on another of his interfaces. > I wonder if a ping -I eth1 255.255.255.255 would accomplish the > goal as well? > This would probably cause a broadcast storm if you are doing a loopback test ;-> Actually now that i think about it, you could probably modify ping to do setsockopt(fd,....,SO_DONTROUTE,...) and send it out on a specific interface. Dont know if it would work. > I would actually like to be able to force a machine to not do local > routing as well, and force packets out over an interface even if > the destination is a local IP, using source-based-routing, > or something similar. There is no way to do this currently? > Try that SO_DONTROUTE and see if solves your problem; you probably have to bind the socket to a specific device as well; For all that trouble, i would suggest you may just as well write a sock packet based app. cheers, jamal From owner-netdev@oss.sgi.com Mon Jun 24 12:24:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5OJO0nC004818 for ; Mon, 24 Jun 2002 12:24:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OJO0sn004817 for netdev-outgoing; Mon, 24 Jun 2002 12:24:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from exalane.intransa.com ([66.89.142.11]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5OJNunC004814 for ; Mon, 24 Jun 2002 12:23:56 -0700 Received: from candelatech.com ([172.30.6.114]) by exalane.intransa.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 24 Jun 2002 12:27:10 -0700 Message-ID: <3D17728C.5060303@candelatech.com> Date: Mon, 24 Jun 2002 12:27:08 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jamal CC: "Bloch, Jack" , "'netdev@oss.sgi.com'" Subject: Re: IP stack question References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jun 2002 19:27:10.0599 (UTC) FILETIME=[22C26170:01C21BB5] Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 835 Lines: 25 jamal wrote: > > On Mon, 24 Jun 2002, Ben Greear wrote: > Try that SO_DONTROUTE and see if solves your problem; you probably have to > bind the socket to a specific device as well; > For all that trouble, i would suggest you may just as well write a sock > packet based app. I want to use normal TCP/IP stack as much as possible, so the sock-packet (or raw) would not work for me, although it would work fine for the original poster. I'm also using source-based routing to send out the correct local interface. I'll have to look up more information on what SO_DONTROUTE does, and thanks for the suggestion! Ben -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From owner-netdev@oss.sgi.com Tue Jun 25 06:53:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5PDrvnC021621 for ; Tue, 25 Jun 2002 06:53:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5PDrvSf021620 for netdev-outgoing; Tue, 25 Jun 2002 06:53:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from loewe.cosy.sbg.ac.at (loewe.cosy.sbg.ac.at [141.201.2.12]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5PDrrnC021617 for ; Tue, 25 Jun 2002 06:53:54 -0700 Received: from mausmaki.cosy.sbg.ac.at (mausmaki.cosy.sbg.ac.at [141.201.2.18]) by loewe.cosy.sbg.ac.at (8.8.8/8.8.7) with ESMTP id PAA20551 for ; Tue, 25 Jun 2002 15:57:16 +0200 (MET DST) Date: Tue, 25 Jun 2002 15:57:16 +0200 (MET DST) From: "Thomas 'Dent' Mirlacher" To: netdev@oss.sgi.com Subject: simple networking clenaup questions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 418 Lines: 18 hi list, i have a some uestions about networking cleanups: 1) is moving the ifmap struct into net_device still on the todo list? (it is according to the comments in the header file) 2) what about getting rid of dev->set_config, and just pass SIOCSIFMAP to the device? thanks, tm -- "They that can give up liberty to obtain a little temporary safety deserve neighter liberty nor safety" - Benjamin Franklin From owner-netdev@oss.sgi.com Thu Jun 27 09:49:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5RGnBnC018836 for ; Thu, 27 Jun 2002 09:49:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5RGnBNW018835 for netdev-outgoing; Thu, 27 Jun 2002 09:49:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from mm02snlnto.sandia.gov (mm02snlnto.sandia.gov [132.175.109.21]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5RGn7nC018831 for ; Thu, 27 Jun 2002 09:49:07 -0700 Received: from 132.175.109.4 by mm02snlnto.sandia.gov with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7)); Thu, 27 Jun 2002 10:50:18 -0600 X-Server-Uuid: 95b8ca9b-fe4b-44f7-8977-a6cb2d3025ff Received: from ES01SNLNT.sandia.gov (es01snlnt.sandia.gov [134.253.130.4]) by mailgate2.sandia.gov (8.12.3/8.12.3) with ESMTP id g5RGqd2B007962 for ; Thu, 27 Jun 2002 10:52:39 -0600 (MDT) Received: by ES01SNLNT.sandia.gov with Internet Mail Service ( 5.5.2653.19) id ; Thu, 27 Jun 2002 10:52:38 -0600 Message-ID: From: "Memon, Mazhar I" To: "'netdev@oss.sgi.com'" Subject: skb_copy() for private linear skb->data Date: Thu, 27 Jun 2002 10:52:38 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Filter-Version: 1.8 (sass2426) X-WSS-ID: 11059DC02269-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 808 Lines: 19 According to the comment above skb_copy(): "As by-product this function converts non-linear &sk_buff to linear one, so that &sk_buff becomes completely private and caller is allowed to modify all the data of returned buffer. " So in order to do some sort of data transformation on skb->data: new_skb = skb_copy(skb, GFP_ATOMIC); encrypt(new_skb->data) with skb_unlink(skb)? with dev_kfree_skb(new_skb)? This causes an oops. Or instead of nuking, and sending, should the list pointers of the two skb's be swapped so that the new_skb appears in the list where 'skb' once lived, and then kfree(skb)? I've tried to find an answer to this simple question in many places without luck. Also, I cannot use skb_linearize, since not all data is made private to the caller. -Mazhar From owner-netdev@oss.sgi.com Fri Jun 28 12:54:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5SJs2nC014775 for ; Fri, 28 Jun 2002 12:54:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5SJs2bm014774 for netdev-outgoing; Fri, 28 Jun 2002 12:54:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5SJrunC014763 for ; Fri, 28 Jun 2002 12:53:56 -0700 Received: from data.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id MAA18210; Fri, 28 Jun 2002 12:57:04 -0700 Received: from mvista.com (IDENT:george@localhost [127.0.0.1]) by data.mvista.com (8.9.3/8.9.3) with ESMTP id MAA28820; Fri, 28 Jun 2002 12:56:31 -0700 Message-ID: <3D1CBF6F.742DB2E2@mvista.com> Date: Fri, 28 Jun 2002 12:56:31 -0700 From: george anzinger Organization: Monta Vista Software X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12-20b i686) X-Accept-Language: en MIME-Version: 1.0 To: Andi Kleen CC: "David S. Miller" , kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, linux-net@vger.kernel.org, pekkas@netcore.fi, andrew.r.cress@intel.com Subject: Re: Network oops References: <20020609.213150.32126725.davem@redhat.com> <3D042F8F.72764243@mvista.com> <3D120EAE.5A0D365E@mvista.com> <20020620.173805.55219901.davem@redhat.com> <3D133538.60B6810C@mvista.com> <20020622025551.A1919@averell> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 655 Lines: 18 We finally found the problem. I want to thank the folks who gave any thought and/or feedback to us, particularly Alexey and David. For what its worth we tracked it down to the kernel memory allocation routines allocating the same buffer to two different network requesters. This in turn was caused by a basic flaw in the preemption code that preempted on spin_unlock, REGARDLESS OF THE STATE OF THE INTERRUPT SYSTEM. -- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Real time sched: http://sourceforge.net/projects/rtsched/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml From owner-netdev@oss.sgi.com Sat Jun 29 07:35:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5TEZknC004585 for ; Sat, 29 Jun 2002 07:35:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5TEZkw5004584 for netdev-outgoing; Sat, 29 Jun 2002 07:35:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-netdev@oss.sgi.com using -f Received: from attila.bofh.it (postfix@attila.bofh.it [213.92.8.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5TEZcnC004573 for ; Sat, 29 Jun 2002 07:35:39 -0700 Received: by attila.bofh.it (Postfix, from userid 10) id 415B15FB63; Sat, 29 Jun 2002 16:39:16 +0200 (CEST) Received: by wonderland.linux.it (Postfix/Md, from userid 1001) id 49D2433DD4; Sat, 29 Jun 2002 16:39:01 +0200 (CEST) Date: Sat, 29 Jun 2002 16:39:01 +0200 From: "Marco d'Itri" To: netdev@oss.sgi.com Cc: ipv6@lists.linux.it Subject: IPv6 ND on PPC hardware Message-ID: <20020629143901.GA1963@wonderland.linux.it> Reply-To: netdev@oss.sgi.com, md@Linux.IT Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Status: No, hits=0.9 required=5.0 tests=URI_IS_POUND version=2.20 X-Spam-Level: Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1987 Lines: 39 I do not understand why ND is not working. Is my configuration wrong or I have exposed a kernel bug? When I try to ping another host on the LAN it usually works the first time, and then stops working because the other host does not replies to ND requests. Apparently verything works again if I switch the interface in promiscuous mode. erode:/# ip -6 ad 1: lo: mtu 16436 qdisc noqueue inet6 ::1/128 scope host 2: eth0: mtu 1500 qdisc pfifo_fast qlen 100 inet6 3ffe:1001:210:16::3/64 scope global inet6 3ffe:8271:a040:16::3/64 scope global inet6 3ffe:8171:10:16::3/64 scope global inet6 fe80::204:acff:fe97:7130/10 scope link erode:/# ip -6 ro 3ffe:1001:210:16::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 3ffe:8171:10:16::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 3ffe:8271:a040:16::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 2000::/3 via 3ffe:1001:210:16::1 dev eth0 metric 1024 mtu 1500 advmss 1440 fe80::/10 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 ff00::/8 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 unreachable default dev lo metric -1 error -101 erode:/# uname -a Linux erode 2.4.19-rc1 #1 Sat Jun 29 15:05:41 CEST 2002 ppc unknown The other host has a similar configuration. Seen from a third host (i386, which appears to work) on the same LAN: 16:23:22.818468 erode.bofh.it > ff02::1:ff00:1: icmp6: neighbor sol: who has attila.bofh.it(src lladdr: 0:4:ac:97:71:30) (len 32, hlim 255) 16:23:23.814589 erode.bofh.it > ff02::1:ff00:1: icmp6: neighbor sol: who has attila.bofh.it(src lladdr: 0:4:ac:97:71:30) (len 32, hlim 255) 16:23:24.814834 erode.bofh.it > ff02::1:ff00:1: icmp6: neighbor sol: who has attila.bofh.it(src lladdr: 0:4:ac:97:71:30) (len 32, hlim 255) 16:23:25.844675 erode.bofh.it > ff02::1:ff00:1: icmp6: neighbor sol: who has attila.bofh.it(src lladdr: 0:4:ac:97:71:30) (len 32, hlim 255) -- ciao, Marco