From Niklas.Edmundsson@hpc2n.umu.se Tue Jul 1 00:37:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jul 2003 00:37:51 -0700 (PDT) Received: from tekla.ing.umu.se (root@tekla.ing.umu.se [130.239.117.80]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h617bS2x004363 for ; Tue, 1 Jul 2003 00:37:30 -0700 Received: from tekla.ing.umu.se (nikke@tekla.ing.umu.se [130.239.117.80]) by tekla.ing.umu.se (8.12.3/8.12.3/Debian-6.4) with ESMTP id h617bQ0j006731 for ; Tue, 1 Jul 2003 09:37:27 +0200 Date: Tue, 1 Jul 2003 09:37:26 +0200 (CEST) From: Niklas Edmundsson X-X-Sender: nikke@tekla.ing.umu.se To: netdev@oss.sgi.com Subject: martian packet checks breaks multi-homing Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3703 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Niklas.Edmundsson@hpc2n.umu.se Precedence: bulk X-list: netdev Hi! We are setting up a multi homed server (currently running Linux 2.4.18) connected to several physical networks (due to the fact that the server is a dhcp server too). All clients talks to the main interface on the machine, routing is done by the network equipment. The problem is that when a client tries to talk to the main interface of the server (not on the same network), the server tags the packets as martian source and discards them! It's a perfectly valid packet since the client is not even aware of the servers extra interface on the network at this point and thus talks to the main interface via the default gateway and the normal routing on the campus network. This feature is desirable if you are doing some sort of routing or firewalling when there are no reason to talk to the other interface, but when doing multi-homing it's not what you want if you have an environment where clients talks to a main interface of a machine to establish communication (due to higher bandwidth or other reasons). I haven't even been able to find a way to disable or circumvent the check other than edit the source (fib_validate_source() is rather hard to read by the way). It would be nice if there existed a runtime way to disable it. I have done this setup a number of times using Solaris and AIX boxes, and it's a simple thing that really ought to work... If things are unclear or I have forgotten/missed something just tell me so and I'll try to clarify. /Nikke -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Niklas Edmundsson, Admin @ {acc,hpc2n,ing}.umu.se | nikke@hpc2n.umu.se --------------------------------------------------------------------------- Egotist: Thinks he's in the groove when he's in a rut =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From nikke@ing.umu.se Tue Jul 1 02:22:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jul 2003 02:23:02 -0700 (PDT) Received: from tekla.ing.umu.se (root@tekla.ing.umu.se [130.239.117.80]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h619Mp2x014958 for ; Tue, 1 Jul 2003 02:22:52 -0700 Received: from tekla.ing.umu.se (nikke@tekla.ing.umu.se [130.239.117.80]) by tekla.ing.umu.se (8.12.3/8.12.3/Debian-6.4) with ESMTP id h619Mo0j009659 for ; Tue, 1 Jul 2003 11:22:50 +0200 Date: Tue, 1 Jul 2003 11:22:50 +0200 (CEST) From: Niklas Edmundsson To: netdev@oss.sgi.com Subject: Re: martian packet checks breaks multi-homing In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3704 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nikke@ing.umu.se Precedence: bulk X-list: netdev On Tue, 1 Jul 2003, Niklas Edmundsson wrote: > > Hi! > > We are setting up a multi homed server (currently running Linux > 2.4.18) connected to several physical networks (due to the fact that > the server is a dhcp server too). > I haven't even been able to find a way to disable or circumvent the > check other than edit the source (fib_validate_source() is rather hard > to read by the way). It would be nice if there existed a runtime way > to disable it. Ignore me. Just after I sent this mail I found /proc/sys/net/ipv4/conf/*/rp_filter which solves all my problems. Sorry for the inconvenience. /Nikke - spanks the paranoid debian startup scripts a bit. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Niklas Edmundsson, Admin @ {acc,hpc2n,ing}.umu.se | nikke@ing.umu.se --------------------------------------------------------------------------- There once was a man from Nantucket.You've been talking to Garibaldi! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From srompf@barkeeper.isg.de Tue Jul 1 02:51:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jul 2003 02:51:51 -0700 (PDT) Received: from mail.isg.de (rzfoobar.is-asp.com [217.11.194.155]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h619pU2x016820 for ; Tue, 1 Jul 2003 02:51:31 -0700 Received: from barkeeper.isg.de (barkeeper.frankfurter-softwarefabrik.de [192.168.6.182]) by mail.isg.de (Postfix) with ESMTP id 6D1C51312C1E; Tue, 1 Jul 2003 11:11:27 +0200 (CEST) Received: from localhost (localhost [[UNIX: localhost]]) by barkeeper.isg.de (8.9.3/8.9.3) id LAA00936; Tue, 1 Jul 2003 11:11:26 +0200 From: Stefan Rompf To: Niklas Edmundsson , netdev@oss.sgi.com Subject: Re: martian packet checks breaks multi-homing Date: Tue, 1 Jul 2003 11:11:05 +0200 User-Agent: KMail/1.5.9.1i References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200307011111.26762.srompf@isg.de> X-archive-position: 3705 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: srompf@isg.de Precedence: bulk X-list: netdev Am Dienstag, 1. Juli 2003 09:37 schrieb Niklas Edmundsson: > The problem is that when a client tries to talk to the main interface > of the server (not on the same network), the server tags the packets > as martian source and discards them! It's a perfectly valid packet > If things are unclear or I have forgotten/missed something just tell > me so and I'll try to clarify. Have a look at linux/Documentation/networking/ip-sysctl.txt, rp_filter Stefan -- "doesn't work" is not a magic word to explain everything. From mtk-lists@gmx.net Tue Jul 1 04:23:57 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jul 2003 04:24:04 -0700 (PDT) Received: from mx0.gmx.net (mx0.gmx.net [213.165.64.100]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61BNt2x020920 for ; Tue, 1 Jul 2003 04:23:56 -0700 Received: (qmail 7717 invoked by uid 0); 1 Jul 2003 11:23:49 -0000 Date: Tue, 1 Jul 2003 13:23:49 +0200 (MEST) From: mtk-lists@gmx.net To: netdev@oss.sgi.com MIME-Version: 1.0 Subject: shutdown() and SHUT_RD on TCP sockets - broken? X-Priority: 3 (Normal) X-Authenticated-Sender: #0018454895@gmx.net X-Authenticated-IP: [212.18.21.202] Message-ID: <14321.1057058629@www1.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-archive-position: 3706 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mtk-lists@gmx.net Precedence: bulk X-list: netdev Hello, I've done quite some searching, but have so far not found an answer to the question of why does the behaviour described below occur on Linux... According to SUSv3, if we perform a shutdown(fd, SHUT_RD) on a socket, then further reads on that socket should be disabled. In the AF_UNIX domain, all is fine -- things operate as I expect. However, for TCP sockets, things are different (tested on 2.2.14, and 2.4.20): 1. If we perform a read() on the socket and there is no data, then 0 (EOF) is (immediately) returned. (This is what I expected.) 2. However, the peer can still write() to the socket, and afterwards we can read() that data from the socket, even though the reading half of the socket should be shut down. Instead of this behaviour, I expected the read() to continue to return 0 as in point 1. This is what we see for example in FreeBSD 4.8, Tru64 5.1B, and HP/UX 11. I thought that most implementations (other than Linux) did things this way, but I've just now gone and tested things on Solaris 8, and it seems to behave in the same way as Linux. I've read the relevant source code to confirm the anomalous behaviour described here. But, why do things happen in this way on Linux? 3. (A side point.) Looking at Stevens UNPv1, p161, there is a statement that after a SHUT_RD, "any data for a TCP socket is acknowledged and then silently discarded". This implies to me that the sender could keep on writing to the socket and never block. However, on Linux, if the peer keeps sending to a socket, then eventually (the channel is filled and) it blocks. I see that this also occurs on FreeBSD 4.8, Tru64 5.1B, HP/UX 11 and Solaris 8. Have I misunderstood Stevens, or has something changed since the implementation he described (or was his statement wrong)? (In the AF_UNIX domain on Linux, the peer gets SIGPIPE/EPIPE if it keeps writing after a local SHUT_RD.) Thanks Michael -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage! From ahu@outpost.ds9a.nl Tue Jul 1 06:27:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jul 2003 06:27:45 -0700 (PDT) Received: from outpost.ds9a.nl (postfix@outpost.ds9a.nl [213.244.168.210]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61DRF2x031102 for ; Tue, 1 Jul 2003 06:27:15 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id D904440F5; Tue, 1 Jul 2003 14:58:08 +0200 (CEST) Date: Tue, 1 Jul 2003 14:58:08 +0200 From: bert hubert To: Andreas Jellinghaus Cc: "netdev@oss.sgi.com" Subject: Re: ipsec without interface Message-ID: <20030701125808.GA19408@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Andreas Jellinghaus , "netdev@oss.sgi.com" References: <1054235787.605.21.camel@simulacron> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1054235787.605.21.camel@simulacron> User-Agent: Mutt/1.3.28i X-archive-position: 3707 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ahu@ds9a.nl Precedence: bulk X-list: netdev On Thu, May 29, 2003 at 09:16:27PM +0200, Andreas Jellinghaus wrote: > sure, the simple configurations work fine with kernel 2.5.* ipsec. > But I miss the interface and things I did with it. How are these > setups supposed to work without an interface? > > a) in iptables allow everything coming from ipsec0, > allow only ssh and ipsec on eth0. iptables can filter on ESP/AH presence. > b) source address selection. put the default route on ipsec0, Do you need a separate source address? -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO From aj@dungeon.inka.de Tue Jul 1 06:31:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jul 2003 06:31:49 -0700 (PDT) Received: from mail.inka.de (mail@quechua.inka.de [193.197.184.2]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61DVW2x031439 for ; Tue, 1 Jul 2003 06:31:33 -0700 Received: from dungeon.inka.de (uucp@[127.0.0.1]) by mail.inka.de with uucp (rmailwrap 0.5) id 19XLEI-0005f6-00; Tue, 01 Jul 2003 15:31:30 +0200 Received: from [192.168.3.1] (unknown [192.168.3.1]) by dungeon.inka.de (Postfix) with ESMTP id F11C421210; Tue, 1 Jul 2003 15:31:24 +0200 (CEST) Subject: Re: ipsec without interface From: Andreas Jellinghaus To: bert hubert Cc: "netdev@oss.sgi.com" In-Reply-To: <20030701125808.GA19408@outpost.ds9a.nl> References: <1054235787.605.21.camel@simulacron> <20030701125808.GA19408@outpost.ds9a.nl> Content-Type: text/plain Message-Id: <1057066404.4054.9.camel@simulacron> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 01 Jul 2003 15:33:24 +0200 Content-Transfer-Encoding: 7bit X-archive-position: 3708 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: aj@dungeon.inka.de Precedence: bulk X-list: netdev On Tue, 2003-07-01 at 14:58, bert hubert wrote: > On Thu, May 29, 2003 at 09:16:27PM +0200, Andreas Jellinghaus wrote: > > sure, the simple configurations work fine with kernel 2.5.* ipsec. > > But I miss the interface and things I did with it. How are these > > setups supposed to work without an interface? > > > > a) in iptables allow everything coming from ipsec0, > > allow only ssh and ipsec on eth0. > > iptables can filter on ESP/AH presence. the packet is seen once as ESP/AH and once as normal (e.g. TCP) packet. where is the connection? how can you see that a packet came in first as ESP/AH packet and was then decrypted, and did not came in without ipsec? with freeswan that was easy: drop everything, unless it is from interface ipsec0. And you always new, packets from ipsec0 came in with valid ipsec encryption, that was easy to make sure. and now? use fwmark? even if that works, its not as easy. > > > b) source address selection. put the default route on ipsec0, > > Do you need a separate source address? I'm a "road warrior", so the local wireless lan gives me a 192.168.* address. For my ipsec tunnel to $company gateway I need get an official address assigned, so I can use that to access the company network, or even the internet (if I don't trust the local network, and don't want unencrypted connections to the internet). I think such a setup will be quite common. local lan some nat company gateway 192.168.0.* <-> 192.168.0.1 <-> 1.2.3.4 ipsec tunnel 1.2.3.5 <-> 1.2.3.4 connetion will use 1.2.3.5 <-> 1.2.3.80 (e.g. company file server, allowing access from 1.2.3.*). ip route del default ip route add default gw 192.168.0.1 src 1.2.3.5 yes, that works. but it's not nice. also company getway needs a ip route add 1.2.3.5 dev eth0/1/2/whatever even though no packet to "1.2.3.5" will ever be on any wire - the packet will be alway encrypted and have a final ip address somewhere in the internet or wireless network. hmm. I haven't tried to use an explicit ipip tunnel. did anyone use ESP in transport mode to encrypt packets of an IPIP tunnel? that might help me. Regards, Andreas From shmulik.hen@intel.com Tue Jul 1 06:44:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jul 2003 06:44:39 -0700 (PDT) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61DiH2x031807 for ; Tue, 1 Jul 2003 06:44:18 -0700 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h61DdQM00581 for ; Tue, 1 Jul 2003 13:39:26 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h61DbKa02239 for ; Tue, 1 Jul 2003 13:37:20 GMT Received: from jrslxjul1.npdj.intel.com ([10.12.254.186]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003070106403620572 ; Tue, 01 Jul 2003 06:40:38 -0700 Date: Tue, 1 Jul 2003 16:44:11 +0300 (IDT) From: Shmulik Hen X-X-Sender: Reply-To: Shmulik Hen To: bond-devel , "Chad N. Tindel" , Jay Vosburgh , Jeff Garzik , linux-netdev cc: Amir Noam , Noam Marom , Shmulik Hen , Tsippy Mendelson Subject: [patch][bonding] Fix change active for ALB/TLB Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3709 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Hi, The following patch fixes bonding's change active interface operation for ALB/TLB modes. It used to incorrectly set the old active interface's state to BACKUP (which is required only for active-backup mode) and would cause that slave not to take part in load sharing. It should be applied on latest net-drivers-2.4 BK tree. -- | Shmulik Hen | | Israel Design Center (Jerusalem) | | LAN Access Division | | Intel Communications Group, Intel corp. | diff -Nuarp linux-2.4.22-pre1-netdrvr1/drivers/net/bonding/bond_main.c linux-2.4.22-pre1-netdrvr1-devel/drivers/net/bonding/bond_main.c --- linux-2.4.22-pre1-netdrvr1/drivers/net/bonding/bond_main.c Mon Jun 30 15:29:56 2003 +++ linux-2.4.22-pre1-netdrvr1-devel/drivers/net/bonding/bond_main.c Mon Jun 30 15:29:57 2003 @@ -385,6 +385,9 @@ * - In conjunction with fix for ifenslave -c, in * bond_change_active(), changing to the already active slave * is no longer an error (it successfully does nothing). + * + * 2003/06/30 - Amir Noam + * - Fixed bond_change_active() for ALB/TLB modes. */ #include @@ -429,8 +432,8 @@ #include "bond_3ad.h" #include "bond_alb.h" -#define DRV_VERSION "2.2.13" -#define DRV_RELDATE "June 25, 2003" +#define DRV_VERSION "2.2.14" +#define DRV_RELDATE "June 30, 2003" #define DRV_NAME "bonding" #define DRV_DESCRIPTION "Ethernet Channel Bonding Driver" @@ -1761,8 +1764,11 @@ static int bond_change_active(struct net (oldactive != NULL)&& (newactive->link == BOND_LINK_UP)&& IS_UP(newactive->dev)) { - bond_set_slave_inactive_flags(oldactive); - bond_set_slave_active_flags(newactive); + if (bond_mode == BOND_MODE_ACTIVEBACKUP) { + bond_set_slave_inactive_flags(oldactive); + bond_set_slave_active_flags(newactive); + } + bond_mc_update(bond, newactive, oldactive); bond_assign_current_slave(bond, newactive); printk("%s : activate %s(old : %s)\n", From jmorris@intercode.com.au Tue Jul 1 07:00:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jul 2003 07:00:43 -0700 (PDT) Received: from blackbird.intercode.com.au (IDENT:vrOxXT2uj4iTAwgLdo5TiySDE/u7yS28@blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61E0S2x003973 for ; Tue, 1 Jul 2003 07:00:30 -0700 Received: from excalibur.intercode.com.au (excalibur.intercode.com.au [203.32.101.12]) by blackbird.intercode.com.au (8.11.6p2/8.9.3) with ESMTP id h61E0Er07026; Wed, 2 Jul 2003 00:00:14 +1000 Date: Wed, 2 Jul 2003 00:00:13 +1000 (EST) From: James Morris To: Andreas Jellinghaus cc: bert hubert , "netdev@oss.sgi.com" Subject: Re: ipsec without interface In-Reply-To: <1057066404.4054.9.camel@simulacron> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3710 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@intercode.com.au Precedence: bulk X-list: netdev On 1 Jul 2003, Andreas Jellinghaus wrote: > hmm. I haven't tried to use an explicit ipip tunnel. > did anyone use ESP in transport mode to encrypt packets > of an IPIP tunnel? that might help me. It's known to work on a gre tunnel (if you manually adjust the mtu), so ipip probably works. - James -- James Morris From ja@ssi.bg Tue Jul 1 14:53:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jul 2003 14:53:51 -0700 (PDT) Received: from u.domain.uli (ja.mac.ssi.bg [217.79.71.194]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61LrZ2x015425 for ; Tue, 1 Jul 2003 14:53:40 -0700 Received: from localhost (IDENT:ja@localhost [127.0.0.1]) by u.domain.uli (8.11.6/8.11.6) with ESMTP id h61LvLG02312; Wed, 2 Jul 2003 00:57:21 +0300 Date: Wed, 2 Jul 2003 00:57:21 +0300 (EEST) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: Ben Greear cc: netdev@oss.sgi.com Subject: Re: send-to-self (was Re: routing bug report for 2.4) In-Reply-To: <3EFFEDD7.5020205@candelatech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3711 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ja@ssi.bg Precedence: bulk X-list: netdev Hello, On Mon, 30 Jun 2003, Ben Greear wrote: > You should be able to easily test most of the changes your code > if you have a machine with two ethernet interfaces and a loopback > cable... ok, tested the 2.5 version, the patch files are updated: http://www.ssi.bg/~ja/#loop - added missing dev_put on ENETDOWN - removed the checks that ignore oif for local routes as Alexey suggests I have tried simple tests: ICMP, telnet. What I see is that the 2.5 rt_set_nexthop() does not set sysctl_ip_default_ttl if res->fi is NULL and that causes the icmp echo packets to use ttl=0. May be there are still some noisy places like arp_set_predefined, it will need further investigation. I'm stopping here, for now. > My requirements are: > > 1) Both ethernet ports communicate over the exernal link, UDP & IP traffic. Done > Third-party programs if possible, thus I set the flag on the interface in > my patch, not on an individual socket, though I do have to BINDTODEVICE and > policy-base base route to get things working right... Now you have 2 options: - bind to src IP: the app needs to be aware for that - ip route replace local IP2 dev DEV2 ... src IP1 table local: the app does not need to be aware to use this feature Now using BINDTODEVICE can cause problems with this feature, because we do not ignore oif for local destinations, you risk to miss the local route and arp_filter to break the things or worse (not tested) > 1b) Allow both same-subnet comm (eth1 & eth2 are on same subnet), and also > routed traffic (eth1 & eth2 have their own default router, similar to the > previously discussed routing setup) all other routes remain unchanged, I hope > 2) Allow normal non-looped communication on the ports, including policy-based routing > based on source addr. hm, you better know what you mean. As expected, this feature has its drawbacks. The safe way is to teach some apps to bind to IP1 and the apps that are unaware for these loops to use the prefsrc and thus to use lo. There is no much space for improvement here but I'm open for suggestions. > Thanks, > Ben Regards -- Julian Anastasov From greearb@candelatech.com Tue Jul 1 15:07:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jul 2003 15:07:23 -0700 (PDT) Received: from grok.yi.org (evrtwa1-ar2-4-33-045-074.evrtwa1.dsl-verizon.net [4.33.45.74]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61M7I2x015866 for ; Tue, 1 Jul 2003 15:07:18 -0700 Received: from candelatech.com (localhost.localdomain [127.0.0.1]) by grok.yi.org (8.12.8/8.12.8) with ESMTP id h61M7CKk018766; Tue, 1 Jul 2003 15:07:12 -0700 Message-ID: <3F020610.2080109@candelatech.com> Date: Tue, 01 Jul 2003 15:07:12 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Anastasov CC: netdev@oss.sgi.com Subject: Re: send-to-self (was Re: routing bug report for 2.4) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3712 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Julian Anastasov wrote: > Hello, > > On Mon, 30 Jun 2003, Ben Greear wrote: > > >>You should be able to easily test most of the changes your code >>if you have a machine with two ethernet interfaces and a loopback >>cable... > > > ok, tested the 2.5 version, the patch files are updated: > > http://www.ssi.bg/~ja/#loop > > - added missing dev_put on ENETDOWN > - removed the checks that ignore oif for local routes as Alexey suggests > > I have tried simple tests: ICMP, telnet. What I see > is that the 2.5 rt_set_nexthop() does not set sysctl_ip_default_ttl if > res->fi is NULL and that causes the icmp echo packets to use > ttl=0. May be there are still some noisy places like arp_set_predefined, > it will need further investigation. I'm stopping here, for now. How did you get telnet to bind to a particular local interface? Also, what ping syntax did you use? Did you have to modify either of these applications to get them to work? I looked at the patch...but don't have a good enough grasp of the routing code to provide a useful critique. I believe my patch _is_ smaller though ;) Thanks, Ben > > >>My requirements are: >> >>1) Both ethernet ports communicate over the exernal link, UDP & IP traffic. > > > Done > > >> Third-party programs if possible, thus I set the flag on the interface in >> my patch, not on an individual socket, though I do have to BINDTODEVICE and >> policy-base base route to get things working right... > > > Now you have 2 options: > > - bind to src IP: the app needs to be aware for that > > - ip route replace local IP2 dev DEV2 ... src IP1 table local: the app > does not need to be aware to use this feature > > Now using BINDTODEVICE can cause problems with this feature, > because we do not ignore oif for local destinations, you risk to > miss the local route and arp_filter to break the things or worse (not > tested) > > >>1b) Allow both same-subnet comm (eth1 & eth2 are on same subnet), and also >> routed traffic (eth1 & eth2 have their own default router, similar to the >> previously discussed routing setup) > > > all other routes remain unchanged, I hope > > >>2) Allow normal non-looped communication on the ports, including policy-based routing >> based on source addr. > > > hm, you better know what you mean. As expected, this feature > has its drawbacks. The safe way is to teach some apps to bind to > IP1 and the apps that are unaware for these loops to use the prefsrc > and thus to use lo. There is no much space for improvement here but > I'm open for suggestions. > > >>Thanks, >>Ben > > > Regards > > -- > Julian Anastasov > -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From linux-netdev@gmane.org Tue Jul 1 15:17:19 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jul 2003 15:17:26 -0700 (PDT) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61MHH2x016286 for ; Tue, 1 Jul 2003 15:17:18 -0700 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19XT27-0006BX-00 for ; Tue, 01 Jul 2003 23:51:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: netdev@oss.sgi.com Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19XT24-0006B5-00 for ; Tue, 01 Jul 2003 23:51:24 +0200 From: Jason Lunz Subject: [PATCH 2.4.22-bk] dev->promiscuity refcounting broken in af_packet.c Date: Tue, 1 Jul 2003 21:51:23 +0000 (UTC) Organization: PBR Streetgang Lines: 99 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@main.gmane.org User-Agent: slrn/0.9.7.4 (Linux) X-archive-position: 3713 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lunz@falooley.org Precedence: bulk X-list: netdev niz@vencraft.com said: > A number of people have mentioned that they get a weird situation > where when they *start* a program that does promiscuous network reads > (with, say, ‘tcpdump –i eth0’). They then get a kernel message > “left promiscuous mode” when the program starts and the message > “entered promiscuous mode” when it exits – the exact opposite of > what should happen. Thanks for finding this! This has been happening to me for over a year, but always so rarely that I never bothered to really track it down. Your patch isn't really correct, though. Aside from the whitespace damage, it doesn't really address the problem. Clamping the refcount at zero only stops the bleeding. The problem is that packet sockets are calling dev_set_promiscuity too many times. For example, if I take an unconfigured interface and do: halfoat:~ # ip link show eth1 9: eth1: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:30:48:41:62:12 brd ff:ff:ff:ff:ff:ff halfoat:~ # ip link set up eth1 halfoat:~ # tcpdump -i eth1 & [1] 457 tcpdump: WARNING: eth1: no IPv4 address assigned tcpdump: listening on eth1 halfoat:~ # ip link set down eth1 tcpdump: pcap_loop: recvfrom: Network is down [1]+ Exit 1 tcpdump -i eth1 halfoat:~ # ip link show eth1 9: eth1: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:30:48:41:62:12 brd ff:ff:ff:ff:ff:ff eth1 is now in promiscuous mode because dev->promiscuity is -1 (!= 0). When the interface goes down, dev_change_flags calls dev_close, which sends NETDEV_DOWN down the netdev notifier chain. Because tcpdump has a packet socket open, packet_notifier calls packet_dev_mclist -> packet_dev_mc -> dev_set_promiscuity. When tcpdump gets ENETDOWN, it aborts, closing the packet socket. af_packet.c's proto_ops->release cleanup method is packet_release. On close(), packet_release calls packet_flush_mclist, which again decrements dev->promiscuity, so when tcpdump exits, dev promiscuity is left at -1. I can't see any reason to be mucking about with the device promiscuity on NETDEV_DOWN and NETDEV_UP events in the first place. The attached patch seems to fix all the cases I can think of. It works properly in both of the above cases, and has also been verified to do the right thing with NETDEV_UNREGISTER events. Jason Index: linux-2.4/net/packet/af_packet.c =================================================================== RCS file: /home/cvs/linux-2.4/net/packet/af_packet.c,v retrieving revision 1.11 diff -u -p -r1.11 af_packet.c --- linux-2.4/net/packet/af_packet.c 12 Jun 2002 23:10:34 -0000 1.11 +++ linux-2.4/net/packet/af_packet.c 1 Jul 2003 20:17:51 -0000 @@ -1378,8 +1378,13 @@ static int packet_notifier(struct notifi po = sk->protinfo.af_packet; switch (msg) { - case NETDEV_DOWN: case NETDEV_UNREGISTER: +#ifdef CONFIG_PACKET_MULTICAST + if (po->mclist) + packet_dev_mclist(dev, po->mclist, -1); + // fallthrough +#endif + case NETDEV_DOWN: if (dev->ifindex == po->ifindex) { spin_lock(&po->bind_lock); if (po->running) { @@ -1396,10 +1401,6 @@ static int packet_notifier(struct notifi } spin_unlock(&po->bind_lock); } -#ifdef CONFIG_PACKET_MULTICAST - if (po->mclist) - packet_dev_mclist(dev, po->mclist, -1); -#endif break; case NETDEV_UP: spin_lock(&po->bind_lock); @@ -1409,10 +1410,6 @@ static int packet_notifier(struct notifi po->running = 1; } spin_unlock(&po->bind_lock); -#ifdef CONFIG_PACKET_MULTICAST - if (po->mclist) - packet_dev_mclist(dev, po->mclist, +1); -#endif break; } } From ja@ssi.bg Tue Jul 1 15:19:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jul 2003 15:19:43 -0700 (PDT) Received: from u.domain.uli (ja.mac.ssi.bg [217.79.71.194]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h61MJa2x016593 for ; Tue, 1 Jul 2003 15:19:38 -0700 Received: from localhost (IDENT:ja@localhost [127.0.0.1]) by u.domain.uli (8.11.6/8.11.6) with ESMTP id h61MNQG02379; Wed, 2 Jul 2003 01:23:26 +0300 Date: Wed, 2 Jul 2003 01:23:25 +0300 (EEST) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: Ben Greear cc: netdev@oss.sgi.com Subject: Re: send-to-self (was Re: routing bug report for 2.4) In-Reply-To: <3F020610.2080109@candelatech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3714 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ja@ssi.bg Precedence: bulk X-list: netdev Hello, On Tue, 1 Jul 2003, Ben Greear wrote: > How did you get telnet to bind to a particular local interface? Also, what I tested telnet with replacing the prefsrc, as result, 'ip route get telnet_server_ip_on_eth1' returns local_ip_from_eth0 as src. telnetd listens as usually to 0.0.0.0, incoming connection comes (IP1->IP2), so the server always gets two different IPs... > ping syntax did you use? Did you have to modify either of these applications > to get them to work? Nooo :) 'ping -I IP1 IP2' or if you set IP2's prefsrc to IP1 then even 'ping IP2' works > I looked at the patch...but don't have a good enough grasp of the routing > code to provide a useful critique. I believe my patch _is_ smaller though ;) At least, we have two alternatives :) I'm still not sure whether the "loop" feature will need some tuning in other netsource places. > Thanks, > Ben Regards -- Julian Anastasov From yoshfuji@linux-ipv6.org Tue Jul 1 17:17:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jul 2003 17:17:47 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h620HK2x019307 for ; Tue, 1 Jul 2003 17:17:34 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h620IRBo030900; Wed, 2 Jul 2003 09:18:27 +0900 Date: Wed, 02 Jul 2003 09:18:25 +0900 (JST) Message-Id: <20030702.091825.72842784.yoshfuji@linux-ipv6.org> To: krkumar@us.ibm.com Cc: davem@redhat.com, netdev@oss.sgi.com, linux-net@vger.kernel.org, yoshfuji@linux-ipv6.org, kuznet@ms2.inr.ac.ru Subject: Re: [PATCH] Prefix List against 2.5.70 (re-done) From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <3F008771.5030206@us.ibm.com> References: <20030627.144752.78715628.davem@redhat.com> <20030628.130602.63704890.yoshfuji@linux-ipv6.org> <3F008771.5030206@us.ibm.com> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3715 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <3F008771.5030206@us.ibm.com> (at Mon, 30 Jun 2003 11:54:41 -0700), Krishna Kumar says: > Well, there are two reason that I can see to not do so (ADDRCONF flag is already > fixed in earlier patch) : : You do not explain why we (or kernel) NEED(s) this. It is not so important how SMALL it is though it may cause problems how LARGE it is. > About your point about the managed flag, I think it is a per interface flag > that gets returned when a request for getting flags on that interface is made. > That's why I have made it per interface as part of a GETLNKFLAGS operation. > I don't understand why you think it is NEWLINK thing (not sure what you mean by > that), since it is a flag information on your existing device that a RA is > advertising. I want to get this information not on receipt of an RA, but when > a request is made. This is design issue; how we should provide L3 per-interface information to userspace; eg. in_device and/or inet6_dev things including per-interface statistics. Since I think it is not appropriate to provide per-interface statistics via RTM_xxxROUTE, so I don't agree to provide the RA infomation (i.e. Manage/Otherconf Flags) via RTM_xxxROUTE. Options: - use RTM_xxxLINK for L3 operation - introduce RTM_xxxIFACE for L3 per-interface operations I really want to hear from other maintainers here... David? Alexey? Well, on moving forward; you can split your patch up to 3 things: 1. fix routing flags 2. provide Managed/Otherconf flags API (3. provide the prefix list API (if it IS required)) I'm not against the first item. We need to discuss on the design related to the 2nd item. I don't think that we really need 3rd item. Thank you. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From kuznet@ms2.inr.ac.ru Tue Jul 1 22:17:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jul 2003 22:17:45 -0700 (PDT) Received: from dub.inr.ac.ru (dub.inr.ac.ru [193.233.7.105]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h625HX2x023753 for ; Tue, 1 Jul 2003 22:17:34 -0700 Received: (from kuznet@localhost) by dub.inr.ac.ru (8.6.13/ANK) id JAA05258; Wed, 2 Jul 2003 09:17:22 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200307020517.JAA05258@dub.inr.ac.ru> Subject: Re: Fw: [PATCH 2.4.22-bk] dev->promiscuity refcounting broken in To: davem@redhat.com (David S. Miller) Date: Wed, 2 Jul 2003 09:17:22 +0400 (MSD) Cc: jmorris@redhat.com, netdev@oss.sgi.com, lunz@falooley.org In-Reply-To: <20030701.155051.104064679.davem@redhat.com> from "David S. Miller" at Jul 01, 2003 03:50:51 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3716 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Hello! > I can't see any reason to be mucking about with the device promiscuity > on NETDEV_DOWN and NETDEV_UP events in the first place. I do not remember why protocols (i.e. IP) withdraw multicast lists on device down too. :-) > The attached > patch seems to fix all the cases I can think of. I think it is right. Actually, if to follow the tradition, we could do the same thing as IP does (remembering that mc record is not loaded), but it looks really useless. Dave, the patch looks OK. Alexey PS. Wow! X-MIME-Autoconverted: from 8bit to quoted-printable by oss.sgi.com id h61MHp2x016322 X-MIME-Autoconverted: from quoted-printable to 8bit by devserv.devel.redhat.com id h61MI0K27113 Mime-Version: 1.0 (modified by Mew) Content-Transfer-Encoding: quoted-printable (modified by Mew) All three agents (oss, redhat and your mailer) are damn smart. Rare mail will pass through this uncorrupted, I guess. :-) From pekkas@netcore.fi Tue Jul 1 22:30:19 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Jul 2003 22:30:56 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h625UH2x024116 for ; Tue, 1 Jul 2003 22:30:18 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h625U7X23499; Wed, 2 Jul 2003 08:30:07 +0300 Date: Wed, 2 Jul 2003 08:30:07 +0300 (EEST) From: Pekka Savola To: Michael Bellion and Thomas Heinz cc: linux-kernel@vger.kernel.org, Subject: Re: [ANNOUNCE] nf-hipac v0.8 released In-Reply-To: <3EFF1349.6020802@hipac.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3717 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev Hi, Thanks for your clarification. We've also conducted some tests with bridging firewall functionality, and we're very pleased with nf-hipac's performance! Results below. In the measurements, tests were run through a bridging Linux firewall, with a netperf UDP stream of 1450 byte packets (launched from a different computer connected with gigabit ethernet), with a varying amount of filtering rules checks for each packet. I don't have the specs of the Linux PC hardware handy, but I recall they're *very* highend dual-P4's, like 2.4Ghz, very fast PCI bus, etc. Shouldn't be a factor here. 1. Filtering based on source address only, for example: $fwcmd -A $MAIN -p udp -s 10.0.0.1 -j DROP ... $fwcmd -A $MAIN -p udp -s 10.0.3.255 -j DROP $fwcmd -A $MAIN -p udp -j ACCEPT Results: rules | plain NF | NF-HIPAC | sent | got thru | sent | got thru | (n.o) | (Mbit/s) | (Mbit/s) | (Mbit/s) | (Mbit/s) | ------------------------------------------------------------- 0 | 956,00 | 953,24 | 956,00 | 953,24 | 512 | 956,00 | 800,68 | 956,46 | 952,81 | 1024 | 956,00 | 472,78 | 956,46 | 952,81 | 2048 | 955,99 | 170,52 | 956,46 | 952,86 | 3072 | 956,00 | 51,97 | 956,46 | 952,85 | 2. Filtering based on UDP protocol's source port, for example: $fwcmd -A $MAIN -p udp --source-port 1 -j DROP ... $fwcmd -A $MAIN -p udp --source-port 1024 -j DROP $fwcmd -A $MAIN -p udp -j ACCEPT Results: rules | plain NF | NF-HIPAC | sent | got thru | sent | got thru | (n.o) | (Mbit/s) | (Mbit/s) | (Mbit/s) | (Mbit/s) | ------------------------------------------------------------- 0 | 955,37 | 954,33 | 956,46 | 952,85 | 512 | 980,68 | 261,41 | 956,46 | 951,92 | 1024 | N/A | N/A | 956,47 | 952,86 | 2048 | N/A | N/A | 956,46 | 952,85 | 3072 | N/A | N/A | 956,46 | 952,85 | N/A = Netfilter bridging can't handle this at all, no traffic can pass the bridge. So, plain Netfilter can tolerate about a couple of hundred rules checking for addresses and/or ports on a gigabit line. With HIPAC Netfilter, packet loss is very low, less than 0.5%, even with the maximum number (of tested) rules, the same amount as without filtering at all. On Sun, 29 Jun 2003, Michael Bellion and Thomas Heinz wrote: > You wrote: > >>We are going to test the stuff tomorrow on an i386 and tell you > >>the results afterwards. > > Well, nf-hipac works fine together with the ebtables patch for 2.4.21 > on an i386 machine. We expect it to work with other patches too. > > >>In principle, nf-hipac should work properly whith the bridge patch. > >>We expect it to work just like iptables apart from the fact that > >>you cannot match on bridge ports. > > Well, this statement holds for the native nf-hipac in/out interface > match but of course you can match on bridge ports with nf-hipac > using the iptables physdev match. So everything should be fine :) > > > One obvious thing that's missing in your performance and Roberto's figures > > is what *exactly* are the non-matching rules. Ie. do they only match IP > > address, a TCP port, or what? (TCP port matching is about a degree of > > complexity more expensive with iptables, I recall.) > > [answered in private e-mail] > > > Regards, > > +-----------------------+----------------------+ > | Michael Bellion | Thomas Heinz | > | | | > +-----------------------+----------------------+ > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From nf@hipac.org Wed Jul 2 05:27:13 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 05:27:19 -0700 (PDT) Received: from indyio.rz.uni-saarland.de (indyio.rz.uni-saarland.de [134.96.7.3]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h62CRB2x032309 for ; Wed, 2 Jul 2003 05:27:13 -0700 Received: from mars.rz.uni-saarland.de (mars.rz.uni-saarland.de [134.96.7.4]) by indyio.rz.uni-saarland.de (8.12.9/8.12.5) with ESMTP id h62CQwfZ012757; Wed, 2 Jul 2003 14:26:59 +0200 (CEST) Received: from e002.stw.stud.uni-saarland.de (e002.stw.stud.uni-saarland.de [134.96.65.17]) by mars.rz.uni-saarland.de (8.9.3p2/8.8.4/8.8.2) with ESMTP id OAA27042; Wed, 2 Jul 2003 14:26:57 +0200 (CEST) Received: from e002.stw.stud.uni-saarland.de ([134.96.65.138] helo=e123.stw.stud.uni-saarland.de) by e002.stw.stud.uni-saarland.de with esmtp (Exim 3.35 #1 (Debian)) id 19XghM-0007HJ-00; Wed, 02 Jul 2003 14:26:56 +0200 From: Michael Bellion and Thomas Heinz Reply-To: nf@hipac.org To: Pekka Savola Subject: Re: [ANNOUNCE] nf-hipac v0.8 released Date: Wed, 2 Jul 2003 14:26:56 +0200 User-Agent: KMail/1.5.2 References: In-Reply-To: Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200307021426.56138.nf@hipac.org> X-archive-position: 3718 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nf@hipac.org Precedence: bulk X-list: netdev Hi Pekka > Thanks for your clarification. We've also conducted some tests with > bridging firewall functionality, and we're very pleased with nf-hipac's > performance! Results below. Great, thanks a lot. Your tests are very interesting for us as we haven't done any gigabit or SMP tests yet. > In the measurements, tests were run through a bridging Linux firewall, > with a netperf UDP stream of 1450 byte packets (launched from a different > computer connected with gigabit ethernet), with a varying amount of > filtering rules checks for each packet. > I don't have the specs of the Linux PC hardware handy, but I recall > they're *very* highend dual-P4's, like 2.4Ghz, very fast PCI bus, etc. Since real world network traffic always consists of a lot of different sized packets taking maximum sized packets is very euphemistic. 1450 byte packets at 950 Mbit/s correspond to approx. 80,000 packets/sec. We are really interested in how our algorithm performs at higher packet rates. Our performance tests are based on 100 Mbit hardware so we coudn't test with more than approx. 80,000 packets/sec even with minimum sized packets. At this packet rate we were hardly able to drive the algorithm to its limit, even with more than 25000 rules involved (and our test system was 1.3 GHz uniprocessor). We'd appreciate it very much if you could run additional tests with smaller packet sizes (including minimum packet size). This way we can get an idea of whether our SMP optimizations work and whether our algorithm in general would benefit from further fine tuning. Regards +-----------------------+----------------------+ | Michael Bellion | Thomas Heinz | | | | +-----------------------+----------------------+ From P@draigBrady.com Wed Jul 2 06:14:48 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 06:14:59 -0700 (PDT) Received: from corvil.com (gate.corvil.net [213.94.219.177]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h62DEj2x000525 for ; Wed, 2 Jul 2003 06:14:47 -0700 Received: from draigBrady.com (pixelbeat.local.corvil.com [172.18.1.170]) by corvil.com (8.12.9/8.12.5) with ESMTP id h62DEWlT084256; Wed, 2 Jul 2003 14:14:33 +0100 (IST) (envelope-from P@draigBrady.com) Message-ID: <3F02D964.7050301@draigBrady.com> Date: Wed, 02 Jul 2003 14:08:52 +0100 From: P@draigBrady.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030617 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nf@hipac.org CC: Pekka Savola , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [ANNOUNCE] nf-hipac v0.8 released References: <200307021426.56138.nf@hipac.org> In-Reply-To: <200307021426.56138.nf@hipac.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by corvil.com id h62DEWlT084256 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h62DEj2x000525 X-archive-position: 3719 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: P@draigBrady.com Precedence: bulk X-list: netdev Michael Bellion and Thomas Heinz wrote: > Hi Pekka > > >>Thanks for your clarification. We've also conducted some tests with >>bridging firewall functionality, and we're very pleased with nf-hipac's >>performance! Results below. > > > Great, thanks a lot. Your tests are very interesting for us as we haven't done > any gigabit or SMP tests yet. > >>In the measurements, tests were run through a bridging Linux firewall, >>with a netperf UDP stream of 1450 byte packets (launched from a different >>computer connected with gigabit ethernet), with a varying amount of >>filtering rules checks for each packet. >>I don't have the specs of the Linux PC hardware handy, but I recall >>they're *very* highend dual-P4's, like 2.4Ghz, very fast PCI bus, etc. > > Since real world network traffic always consists of a lot of different sized > packets taking maximum sized packets is very euphemistic. 1450 byte packets > at 950 Mbit/s correspond to approx. 80,000 packets/sec. > We are really interested in how our algorithm performs at higher packet rates. > Our performance tests are based on 100 Mbit hardware so we coudn't test with > more than approx. 80,000 packets/sec even with minimum sized packets. Interrupt latency is the problem here. You'll require napi et. al to get over this hump. > At this > packet rate we were hardly able to drive the algorithm to its limit, even > with more than 25000 rules involved (and our test system was 1.3 GHz > uniprocessor). Cool. The same sort of test with ordinary netfilter that I did showed it could only handle around 125 rules at this packet rate on a 1.4GHz PIII, e1000 @ 100Mb/s. # ./readprofile -m /boot/System.map | sort -nr | head -30 6779 total 0.0047 4441 default_idle 69.3906 787 handle_IRQ_event 7.0268 589 ip_packet_match 1.6733 433 ipt_do_table 0.6294 106 eth_type_trans 0.5521 56 kfree 0.8750 46 skb_release_data 0.3194 37 add_timer_randomness 0.1542 35 alloc_skb 0.0781 30 __kmem_cache_alloc 0.1172 27 kmalloc 0.3375 23 ip_rcv 0.0342 22 do_gettimeofday 0.1964 20 netif_rx 0.0521 19 __kfree_skb 0.0540 18 add_entropy_words 0.1023 15 __constant_c_and_count_memset 0.0938 13 batch_entropy_store 0.0813 12 kfree_skbmem 0.1071 11 netif_receive_skb 0.0208 7 nf_iterate 0.0437 7 nf_hook_slow 0.0175 6 process_backlog 0.0221 5 batch_entropy_process 0.0223 5 add_interrupt_randomness 0.0781 3 kmem_cache_free 0.0625 2 ipt_hook 0.0312 1 write_profile 0.0156 1 ip_promisc_rcv_finish 0.0208 Pádraig. From nf@hipac.org Wed Jul 2 06:48:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 06:48:39 -0700 (PDT) Received: from indyio.rz.uni-saarland.de (indyio.rz.uni-saarland.de [134.96.7.3]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h62DmT2x001337 for ; Wed, 2 Jul 2003 06:48:30 -0700 Received: from mars.rz.uni-saarland.de (mars.rz.uni-saarland.de [134.96.7.4]) by indyio.rz.uni-saarland.de (8.12.9/8.12.5) with ESMTP id h62DmLfZ032855; Wed, 2 Jul 2003 15:48:21 +0200 (CEST) Received: from e002.stw.stud.uni-saarland.de (e002.stw.stud.uni-saarland.de [134.96.65.17]) by mars.rz.uni-saarland.de (8.9.3p2/8.8.4/8.8.2) with ESMTP id PAA113215; Wed, 2 Jul 2003 15:48:20 +0200 (CEST) Received: from e002.stw.stud.uni-saarland.de ([134.96.65.138] helo=e123.stw.stud.uni-saarland.de) by e002.stw.stud.uni-saarland.de with esmtp (Exim 3.35 #1 (Debian)) id 19Xhy8-0007Pk-00; Wed, 02 Jul 2003 15:48:20 +0200 From: Michael Bellion and Thomas Heinz Reply-To: nf@hipac.org To: P@draigbrady.com Subject: Re: [ANNOUNCE] nf-hipac v0.8 released Date: Wed, 2 Jul 2003 15:48:19 +0200 User-Agent: KMail/1.5.2 References: <200307021426.56138.nf@hipac.org> <3F02D964.7050301@draigBrady.com> In-Reply-To: <3F02D964.7050301@draigBrady.com> Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200307021548.19989.nf@hipac.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h62DmT2x001337 X-archive-position: 3720 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nf@hipac.org Precedence: bulk X-list: netdev Hi Pádraig > > Since real world network traffic always consists of a lot of different > > sized packets taking maximum sized packets is very euphemistic. 1450 byte > > packets at 950 Mbit/s correspond to approx. 80,000 packets/sec. > > We are really interested in how our algorithm performs at higher packet > > rates. Our performance tests are based on 100 Mbit hardware so we coudn't > > test with more than approx. 80,000 packets/sec even with minimum sized > > packets. > > Interrupt latency is the problem here. You'll require napi et. al > to get over this hump. Yes we know, but with 128 byte frame size you can archieve a packet rate of at most 97,656 packets/sec (in theory) on 100 Mbit hardware. We don't think this few more packets would have changed the results fundamentally, so it's probably not worth it on 100 Mbit. Certainly you are right, that napi is required on gigabit to saturate the link with small sized packets. > Cool. The same sort of test with ordinary netfilter that > I did showed it could only handle around 125 rules at this > packet rate on a 1.4GHz PIII, e1000 @ 100Mb/s. > > # ./readprofile -m /boot/System.map | sort -nr | head -30 > 6779 total 0.0047 > 4441 default_idle 69.3906 > 787 handle_IRQ_event 7.0268 > 589 ip_packet_match 1.6733 > 433 ipt_do_table 0.6294 > 106 eth_type_trans 0.5521 > [...] What do you want to show with this profile? Most of the time is spend in the idle loop and in icq handling and only a few percentage in ip_packet_match and ipt_do_table, so we don't quite get how this matches your statement above. Could you explain this in a few words? Regards, +-----------------------+----------------------+ | Michael Bellion | Thomas Heinz | | | | +-----------------------+----------------------+ From or@logreport.org Wed Jul 2 07:00:25 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 07:00:28 -0700 (PDT) Received: from hibou.logreport.org (postfix@logreport.IAE.nl [212.61.24.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h62E0N2x001805 for ; Wed, 2 Jul 2003 07:00:24 -0700 Received: by hibou.logreport.org (Postfix, from userid 1005) id CBEC3C052; Wed, 2 Jul 2003 16:00:21 +0200 (CEST) Content-Type: text/plain; name="lr_log2mail.common.lr_tag-20030702160003-4776.4NuBoD.errors" Content-Disposition: inline; filename="lr_log2mail.common.lr_tag-20030702160003-4776.4NuBoD.errors" MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) To: netdev@oss.sgi.com From: log@logreport.org Subject: [LogReport] Error in common report (was: [LogReport] common report (was: Re: Movie)) Reply-To: support@logreport.org Message-Id: <20030702140021.CBEC3C052@hibou.logreport.org> Date: Wed, 2 Jul 2003 16:00:21 +0200 (CEST) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h62E0N2x001805 X-archive-position: 3721 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: log@logreport.org Precedence: bulk X-list: netdev WARNING: Logfile may be bogus. There were 319 errors on the 319 lines in the log. This may be because you sent a log file that doesn't strictly contain common logs. This is probable if you sent a syslog log file without filtering it to keep only the logs relevant to the common service. It could also be because you sent a log file in the wrong format or a file that isn't a common log file. A report was generated for the 0 records that could be extracted from your log file. From P@draigBrady.com Wed Jul 2 07:29:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 07:29:28 -0700 (PDT) Received: from corvil.com (gate.corvil.net [213.94.219.177]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h62ETG2x002532 for ; Wed, 2 Jul 2003 07:29:18 -0700 Received: from draigBrady.com (pixelbeat.local.corvil.com [172.18.1.170]) by corvil.com (8.12.9/8.12.5) with ESMTP id h62ETAlT092982; Wed, 2 Jul 2003 15:29:14 +0100 (IST) (envelope-from P@draigBrady.com) Message-ID: <3F02EAE2.8050609@draigBrady.com> Date: Wed, 02 Jul 2003 15:23:30 +0100 From: P@draigBrady.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030617 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nf@hipac.org CC: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [ANNOUNCE] nf-hipac v0.8 released References: <200307021426.56138.nf@hipac.org> <3F02D964.7050301@draigBrady.com> <200307021548.19989.nf@hipac.org> In-Reply-To: <200307021548.19989.nf@hipac.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by corvil.com id h62ETAlT092982 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h62ETG2x002532 X-archive-position: 3722 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: P@draigBrady.com Precedence: bulk X-list: netdev Michael Bellion and Thomas Heinz wrote: > Hi Pádraig > > >>>Since real world network traffic always consists of a lot of different >>>sized packets taking maximum sized packets is very euphemistic. 1450 byte >>>packets at 950 Mbit/s correspond to approx. 80,000 packets/sec. >>>We are really interested in how our algorithm performs at higher packet >>>rates. Our performance tests are based on 100 Mbit hardware so we coudn't >>>test with more than approx. 80,000 packets/sec even with minimum sized >>>packets. >> >>Interrupt latency is the problem here. You'll require napi et. al >>to get over this hump. > > Yes we know, but with 128 byte frame size you can archieve a packet rate of at > most 97,656 packets/sec (in theory) on 100 Mbit hardware. We don't think this > few more packets would have changed the results fundamentally, so it's > probably not worth it on 100 Mbit. I was testing with 64 byte packets (so around 190Kpps). e100 cards at least have a handy mode for continually sending a packet as fast as possible. Also you can use more than one interface. So 100Mb is very useful for testing. For the test below I was using a rate of around 85Kpps. > Certainly you are right, that napi is required on gigabit to saturate the link > with small sized packets. > >>Cool. The same sort of test with ordinary netfilter that >>I did showed it could only handle around 125 rules at this >>packet rate on a 1.4GHz PIII, e1000 @ 100Mb/s. >> >># ./readprofile -m /boot/System.map | sort -nr | head -30 >> 6779 total 0.0047 >> 4441 default_idle 69.3906 >> 787 handle_IRQ_event 7.0268 >> 589 ip_packet_match 1.6733 >> 433 ipt_do_table 0.6294 >> 106 eth_type_trans 0.5521 >> [...] > > What do you want to show with this profile? Most of the time is spend in the > idle loop and in irq handling and only a few percentage in ip_packet_match > and ipt_do_table, so we don't quite get how this matches your statement > above. Could you explain this in a few words? Confused me too. The system would lock up and start dropping packets after 125 rules. I.E. it would linearly degrade as more rules were added. I'm guessing there is a fixed interrupt overhead that is accounted for by default_idle? Note the e1000 drivers were left in the default config so there could definitely be some tuning done here. Note I changed netfilter slightly to accept promiscuous traffic which is done in ip_rcv() and then the packets are just dropped after the (match any in the test case) rules are traversed. Pádraig. From or@logreport.org Wed Jul 2 07:33:23 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 07:33:30 -0700 (PDT) Received: from hibou.logreport.org (postfix@logreport.IAE.nl [212.61.24.7]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h62EXB2x002870 for ; Wed, 2 Jul 2003 07:33:12 -0700 Received: by hibou.logreport.org (Postfix, from userid 1005) id 106D5C039; Wed, 2 Jul 2003 16:00:21 +0200 (CEST) Content-Type: text/plain; name="report.txt" Content-Disposition: inline; filename="report.txt" MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) To: netdev@oss.sgi.com From: log@logreport.org Subject: [LogReport] common report (was: Re: Movie) Reply-To: support@logreport.org Message-Id: <20030702140021.106D5C039@hibou.logreport.org> Date: Wed, 2 Jul 2003 16:00:21 +0200 (CEST) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h62EXB2x002870 X-archive-position: 3723 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: log@logreport.org Precedence: bulk X-list: netdev Report generated: 2003-07-02 16:00:16 CEST Reporting on period: Unknown Period Activity Reports ---------------- Number of Requests Served by 1d Period No content in report. Total Size of Requests Served By 1d Period No content in report. User Sessions By 1d Period No content in report. Number of Requests Served by 1h Timeslot Timeslot Requests % Total ------------------------------------------------------- -------- ------- 00:00 0 NaN 01:00 0 NaN 02:00 0 NaN 03:00 0 NaN 04:00 0 NaN 05:00 0 NaN 06:00 0 NaN 07:00 0 NaN 08:00 0 NaN 09:00 0 NaN 10:00 0 NaN 11:00 0 NaN 12:00 0 NaN 13:00 0 NaN 14:00 0 NaN 15:00 0 NaN 16:00 0 NaN 17:00 0 NaN 18:00 0 NaN 19:00 0 NaN 20:00 0 NaN 21:00 0 NaN 22:00 0 NaN 23:00 0 NaN Number of Requests by Request's Size No content in report. Total size of requests served by directory, Top 10 No content in report. Visitors Reports ---------------- Number of Requests by Client Hosts, Top 10 No content in report. Total size of requests by Client Hosts, Top 10 No content in report. Requests By Top Level Domain The "top level domain" is determined from the hostname of the client. There is no real correlation to where the user is geographically located. For example, a client connecting from the hostname ppp10.nl-div.globalcorp.co.uk will get listed as a United Kindom top level domain, even when that user is connecting from a division in The Netherlands. No content in report. Accessed Pages Reports ---------------------- Applied filter in this section: excluded requests matching "\.(png|gif|jpg|jpeg|css)$" Number of Requests Served by 1d Period No content in report. Most Requested Pages, Top 10 No content in report. Most Requested URLs, Top 10, Top 5 URLs No content in report. Session Reports --------------- First Page In User Session, Top 10 - means that only images were requested. No content in report. Last Page In User Session, Top 10 - means that only images were requested. No content in report. User Sessions by Their Recurrence No content in report. Visit Duration Duration is given in seconds. No content in report. Number of Pages per Visit No content in report. Top Traversals, Top 10 Start Page, Top 5 2nd Pages, Top 5 3rd Page No content in report. Download Reports ---------------- Applied filter in this section: selected requests matching \.(gz|tgz|zip|exe|pdf|doc)$ Number of Requests Served by 1d Period No content in report. Most Requested Pages, Top 10 No content in report. Most Requested URLs, Top 10, Top 5 URLs No content in report. Browsers and Platforms Reports ------------------------------ Top 10 Requests By Browser The "browser" is determined from the User-Agent header. It is possible for a user to change that string. This means that the value Internet Explorer could be sent by a user running a customized version of Mozilla. No content in report. Top 10 Requests By Operating System The "operating system" is determined from the User-Agent header. It is possible for a user to change that string. This means that the value Mac PowerPC could be attributed to a user who is really running a customized version of Mozilla under GNU/Linux. No content in report. Top 10 Requests By Browser Language The "language" is determined from the User-Agent header. Users can set this variable to indicate their preferred language. No content in report. Top 10 Requests By Robot No content in report. Search Engines and "Referers" ----------------------------- Applied filter in this section: excluded requests with a referer matching "^-$" Top 10 Referring Sites No content in report. Top 10 Referring Pages No content in report. Top Referring Pages By Requested Page, Top 5 Referrers, Top 10 Pages No content in report. Most Travelled Referer -> Pages Connection, Top 10 No content in report. Requests By Search Engine No content in report. Requests By Keywords, Top 10 No content in report. Requests by Search Engine with Keywords, Top 10 Search Engines, Top 5 Keywords No content in report. Abuse Reports ------------- Requests By Attack No content in report. Compression Reports ------------------- Requests By Gzip Result No content in report. Most Average Compressed Requested URL, Top 10 Compression is in percent. No content in report. File Types With Highest Average Compression Level, Top 10 Compression is in percent. No content in report. Technical Reports ----------------- Requests By HTTP Method No content in report. Requests By HTTP Protocol Version No content in report. Requests By HTTP Result The most common HTTP status codes are given below: 200 OK (The request has succeeded.) 201 Created (The request has been fulfilled and resulted in a new resource being created.) 206 Partial Content (The server has fulfilled the partial GET request for the resource.) 301 Moved Permanently (The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs.) 302 Found (The requested resource resides temporarily under a different URI.) 304 Not Modified (The client has performed a conditional GET request and access is allowed, but the document has not been modified.) 403 Forbidden (The server understood the request, but is refusing to fulfill it.) 404 Not Found (The server has not found anything matching the Request-URI.) No content in report. Requests by Client Hosts By HTTP Result, Top 5 Clients No content in report. Requests by URL By HTTP Result, Top 5 URLs No content in report. -- LogReport sent to you by http://www.LogReport.org/ or@hibou.logreport.org mailto:logreport@logreport.org running lire-1.3.tar.gz The Online Report Responder Service is free of charge. We do not accept any liability however incurred in respect of a failure to perform as is imputable to the same for any loss direct or indirect. If you use the responder on a regular basis, please subscribe to our announcement mailing list (http://logreport.org/contact/lists/) to keep informed on updates and modification to the service. To support the online responder, make a donation to the LogReport Foundation (http://logreport.org/about/donate.php). From Larry.Sendlosky@storigen.com Wed Jul 2 07:59:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 07:59:49 -0700 (PDT) Received: from xchangeserver2.storigen.com ([65.193.106.66]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h62Exi2x003368 for ; Wed, 2 Jul 2003 07:59:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: e1000 in 2.4.21 and carrier errors Date: Wed, 2 Jul 2003 10:59:31 -0400 Message-ID: <7BFCE5F1EF28D64198522688F5449D5A01FF2AF7@xchangeserver2.storigen.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: e1000 in 2.4.21 and carrier errors Thread-Index: AcNAqop9ROmFxCNxTqOmxIx5r8BIYg== From: "Larry Sendlosky" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h62Exi2x003368 X-archive-position: 3724 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Larry.Sendlosky@storigen.com Precedence: bulk X-list: netdev We started running 2.4.21 and use the e1000 driver in the kernel. Our NICs are PRO-1000 82543GC based copper. Using the new driver we see constant increase in carrier errors. Loading the Intel e1000 v3.6.8.1 driver we have no carrier errors. This happens on all our systems with the PR0-1000 card using 2.4.21 and RH9. Switches are a mixture of Dell, Asante, Cisco, and Extreme. Any ideas? thanks larry From jmorris@intercode.com.au Wed Jul 2 09:01:11 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 09:01:15 -0700 (PDT) Received: from blackbird.intercode.com.au (IDENT:FHRUnQvXcBJGTwFDC/PQq8eV2MOvvdEj@blackbird.intercode.com.au [203.32.101.10]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h62G172x004202 for ; Wed, 2 Jul 2003 09:01:09 -0700 Received: from excalibur.intercode.com.au (excalibur.intercode.com.au [203.32.101.12]) by blackbird.intercode.com.au (8.11.6p2/8.9.3) with ESMTP id h62G09r13320; Thu, 3 Jul 2003 02:00:10 +1000 Date: Thu, 3 Jul 2003 02:00:09 +1000 (EST) From: James Morris To: kuznet@ms2.inr.ac.ru cc: "David S. Miller" , , , Subject: Re: Fw: [PATCH 2.4.22-bk] dev->promiscuity refcounting broken in In-Reply-To: <200307020517.JAA05258@dub.inr.ac.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3725 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@intercode.com.au Precedence: bulk X-list: netdev On Wed, 2 Jul 2003 kuznet@ms2.inr.ac.ru wrote: > Dave, the patch looks OK. Applied to bk://kernel.bkbits.net/jmorris/net-2.5 and bk://kernel.bkbits.net/jmorris/net-2.4 - James -- James Morris From nf@hipac.org Wed Jul 2 09:58:11 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 09:58:22 -0700 (PDT) Received: from indyio.rz.uni-saarland.de (indyio.rz.uni-saarland.de [134.96.7.3]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h62Gw92x005473 for ; Wed, 2 Jul 2003 09:58:10 -0700 Received: from mars.rz.uni-saarland.de (mars.rz.uni-saarland.de [134.96.7.4]) by indyio.rz.uni-saarland.de (8.12.9/8.12.5) with ESMTP id h62Gw3fZ067817; Wed, 2 Jul 2003 18:58:03 +0200 (CEST) Received: from e002.stw.stud.uni-saarland.de (e002.stw.stud.uni-saarland.de [134.96.65.17]) by mars.rz.uni-saarland.de (8.9.3p2/8.8.4/8.8.2) with ESMTP id SAA279378; Wed, 2 Jul 2003 18:58:02 +0200 (CEST) Received: from e226.stw.stud.uni-saarland.de ([134.96.65.241] helo=hipac.org) by e002.stw.stud.uni-saarland.de with esmtp (Exim 3.35 #1 (Debian)) id 19Xkvi-0007iJ-00; Wed, 02 Jul 2003 18:58:02 +0200 Message-ID: <3F030EFC.7090809@hipac.org> Date: Wed, 02 Jul 2003 18:57:32 +0200 From: Michael Bellion and Thomas Heinz User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 X-Accept-Language: de, en MIME-Version: 1.0 To: P@draigbrady.com CC: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [ANNOUNCE] nf-hipac v0.8 released References: <200307021426.56138.nf@hipac.org> <3F02D964.7050301@draigBrady.com> <200307021548.19989.nf@hipac.org> <3F02EAE2.8050609@draigBrady.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by indyio.rz.uni-saarland.de id h62Gw3fZ067817 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h62Gw92x005473 X-archive-position: 3726 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nf@hipac.org Precedence: bulk X-list: netdev Hi Pádraig You wrote: > I was testing with 64 byte packets (so around 190Kpps). e100 cards at > least have a handy mode for continually sending a packet as fast as > possible. Also you can use more than one interface. Yes, that's true. When we did the performance tests we had in mind to compare the worst case behaviour of nf-hipac and iptables. Therefore we designed a ruleset which models the worst case for both iptables and nf-hipac. Of course, the test environment could have been tuned a lot more, e.g. udp instead of tcp, FORWARD chain instead of INPUT, tuned network parameters, more interfaces etc. Anyway, we prefer independent, more sophisticated performance tests. >>> # ./readprofile -m /boot/System.map | sort -nr | head -30 >>> 6779 total 0.0047 >>> 4441 default_idle 69.3906 >>> 787 handle_IRQ_event 7.0268 >>> 589 ip_packet_match 1.6733 >>> 433 ipt_do_table 0.6294 >>> 106 eth_type_trans 0.5521 >>> [...] > > Confused me too. The system would lock up and start dropping > packets after 125 rules. I.E. it would linearly degrade > as more rules were added. I'm guessing there is a fixed > interrupt overhead that is accounted for > by default_idle? Hm, but once the system starts to drop packets ip_packet_match and ipt_do_table start to dominate the profile, don't they? Regards, +-----------------------+----------------------+ | Michael Bellion | Thomas Heinz | | | | +-----------------------+----------------------+ From yoshfuji@linux-ipv6.org Wed Jul 2 10:54:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 10:54:22 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h62HsD2x006724 for ; Wed, 2 Jul 2003 10:54:15 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-5) with ESMTP id h62HtTBo003477; Thu, 3 Jul 2003 02:55:30 +0900 Date: Thu, 03 Jul 2003 02:55:29 +0900 (JST) Message-Id: <20030703.025529.100658086.yoshfuji@linux-ipv6.org> To: davem@redhat.com, jmorris@intercode.com.au CC: netdev@oss.sgi.com Subject: [PATCH] IPV6: fix a mistake in ipv6_advmss() conversion From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3727 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Hello. Sorry, I introduced a bug in ipv6_advmss() while converting advmss calculation to inline function. This patch fixes the bug. Index: linux-2.5/net/ipv6/route.c =================================================================== RCS file: /home/cvs/linux-2.5/net/ipv6/route.c,v retrieving revision 1.43 diff -u -r1.43 route.c --- linux-2.5/net/ipv6/route.c 28 Jun 2003 03:58:20 -0000 1.43 +++ linux-2.5/net/ipv6/route.c 2 Jul 2003 16:25:04 -0000 @@ -602,6 +602,8 @@ static inline unsigned int ipv6_advmss(unsigned int mtu) { + mtu -= sizeof(struct ipv6hdr) + sizeof(struct tcphdr); + if (mtu < ip6_rt_min_advmss) mtu = ip6_rt_min_advmss; -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From scott.feldman@intel.com Wed Jul 2 13:53:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 13:53:22 -0700 (PDT) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h62KrF2x008796 for ; Wed, 2 Jul 2003 13:53:15 -0700 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h62KmMB03526 for ; Wed, 2 Jul 2003 20:48:22 GMT Received: from fmsmsxv040-1.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108]) by petasus.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h62KkGZ09881 for ; Wed, 2 Jul 2003 20:46:16 GMT Received: from [134.134.179.196] ([134.134.179.196]) by fmsmsxv040-1.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003070213524023002 ; Wed, 02 Jul 2003 13:52:40 -0700 Date: Wed, 2 Jul 2003 14:09:09 -0700 (PDT) From: "Feldman, Scott" X-X-Sender: scott.feldman@localhost.localdomain Reply-To: "Feldman, Scott" To: Larry Sendlosky cc: netdev@oss.sgi.com Subject: Re: e1000 in 2.4.21 and carrier errors In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3728 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev On Wed, 2 Jul 2003, Larry Sendlosky wrote: > We started running 2.4.21 and use the e1000 driver in the kernel. Our > NICs are PRO-1000 82543GC based copper. Using the new driver we see > constant increase in carrier errors. Loading the Intel e1000 v3.6.8.1 > driver we have no carrier errors. This happens on all our systems with > the PR0-1000 card using 2.4.21 and RH9. Switches are a mixture of Dell, > Asante, Cisco, and Extreme. > > Any ideas? Hi Larry, apply this patch to 3.6.8.1 and see if you get carrier errors. Looks to me like a bug that was fixed in later drivers. Doesn't explain why we're getting carrier errors, but this will let us moved forward to 2.4.21. What are you testing with? Do you have any newer adapters (82544/5/6) you could try in the same setup? -scott diff -Naurp e1000-3.6.8.1/src/e1000_main.c e1000-3.6.8.1-mod/src/e1000_main.c --- e1000-3.6.8.1/src/e1000_main.c 2001-12-28 15:06:18.000000000 -0800 +++ e1000-3.6.8.1-mod/src/e1000_main.c 2003-07-02 14:03:02.000000000 -0700 @@ -2928,6 +2928,7 @@ UpdateStatsCounters(struct adapter * Ada Adapter->net_stats.tx_aborted_errors = Adapter->Ecol; Adapter->net_stats.tx_fifo_errors = Adapter->Tuc; Adapter->net_stats.tx_window_errors = Adapter->Latecol; + Adapter->net_stats.tx_carrier_errors = Adapter->Tncrs; /* Tx Dropped needs to be maintained elsewhere */ From latten@austin.ibm.com Wed Jul 2 16:50:05 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 16:50:11 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h62No42x012030 for ; Wed, 2 Jul 2003 16:50:05 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h62NnJxe106086; Wed, 2 Jul 2003 19:49:19 -0400 Received: from austin.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h62NnGsH202560; Wed, 2 Jul 2003 17:49:17 -0600 Received: from faith.austin.ibm.com (faith.austin.ibm.com [9.41.94.16]) by austin.ibm.com (8.12.9/8.12.9) with ESMTP id h62NnGTi030114; Wed, 2 Jul 2003 18:49:16 -0500 Received: from faith.austin.ibm.com (localhost.localdomain [127.0.0.1]) by faith.austin.ibm.com (8.12.5/8.12.8) with ESMTP id h62NsOIY002989; Wed, 2 Jul 2003 18:54:24 -0500 Received: (from jml@localhost) by faith.austin.ibm.com (8.12.5/8.12.5/Submit) id h62NsMYP002987; Wed, 2 Jul 2003 18:54:23 -0500 Date: Wed, 2 Jul 2003 18:54:23 -0500 From: latten@austin.ibm.com Message-Id: <200307022354.h62NsMYP002987@faith.austin.ibm.com> To: netdev@oss.sgi.com Subject: IPSecv6 AH doesn't work with Fragmenting Cc: davem@redhat.com, kuznet@ms2.inr.ac.ru X-archive-position: 3729 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: latten@austin.ibm.com Precedence: bulk X-list: netdev I am using netperf to stress IPSecv6 with AH protocol. Netperf sent a stream of TCP packets to the receiver. I examined the log on my receiver and saw many "IPSec ah authentication error" messages. I then sniffed my incoming packets and saw that they had been fragmented and each fragment was reported as being malformed. Source Destination Protocol Info 1 fec0:0:0:105::56 fec0:0:0:105::55 TCP 32780 > 32772 [ACK]... 2 fec0:0:0:105::56 fec0:0:0:105::55 AH AH (SPI=0x00000000)[Malformed Packet] 3 fec0:0:0:105::55 fec0:0:0:105::56 TCP 32772 > 32780 [ACK]... 4 fec0:0:0:105::56 fec0:0:0:105::55 TCP 32780 > 32772 [ACK]... 5 fec0:0:0:105::56 fec0:0:0:105::55 AH AH (SPI=0x00000000)[ Malformed Packet] Just for the heck of it, I did a "ping6 -s 1800" and sniffed the wire and although the ping/ICMPv6 works fine in that I get a reply and no authentication failures are logged, my packets are reported as being malformed. It seems AH with fragmenting is not working properly and perhaps that is the cause of all the AH authentication errors I see in my log. Unfortunately I could not cut and paste my ethereal output but if anyone is interested I could send it. It is also easy to reproduce. Just configure AHv6 manually between two machines and run netperf or ping6 -s or anything that would result in fragmentation. Joy From zwane@arm.linux.org.uk Wed Jul 2 17:16:19 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 17:16:32 -0700 (PDT) Received: from hemi.commfireservices.com ([66.212.224.118]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h630GF2x012524 for ; Wed, 2 Jul 2003 17:16:18 -0700 Received: from montezuma.mastecende.com (cuda.commfireservices.com [24.203.207.204]) by hemi.commfireservices.com (Postfix) with ESMTP id 59C34BC51; Wed, 2 Jul 2003 20:06:02 -0400 (EDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by montezuma.mastecende.com (8.12.8/8.12.8) with ESMTP id h63053vo011678; Wed, 2 Jul 2003 20:05:03 -0400 Date: Wed, 2 Jul 2003 20:05:03 -0400 (EDT) From: Zwane Mwaikambo X-X-Sender: zwane@montezuma.mastecende.com To: "Feldman, Scott" Cc: netdev@oss.sgi.com Subject: RE: e1000 lockup with port io type reset In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3730 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zwane@arm.linux.org.uk Precedence: bulk X-list: netdev On Sat, 28 Jun 2003, Zwane Mwaikambo wrote: > Thanks, i just have to wait on the dmi decode. I'll have it to you ASAP. Here we go; # dmidecode 2.1 SMBIOS 2.3 present. 46 structures occupying 1342 bytes. Table at 0x000F2970. Handle 0x0000 DMI type 0, 20 bytes. BIOS Information Vendor: Award Software, Inc. Version: ASUS CUV4X-E ACPI BIOS Revision 1004 Release Date: 07/25/2001 Address: 0xF0000 Runtime Size: 64 kB ROM Size: 256 kB Characteristics: PCI is supported PNP is supported APM is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported Selectable boot is supported BIOS ROM is socketed EDD is supported 5.25"/360 KB floppy services are supported (int 13h) 5.25"/1.2 MB floppy services are supported (int 13h) 3.5"/720 KB floppy services are supported (int 13h) 3.5"/2.88 MB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) CGA/mono video services are supported (int 10h) ACPI is supported AGP is supported Handle 0x0001 DMI type 1, 25 bytes. System Information Manufacturer: System Manufacturer Product Name: System Name Version: System Version Serial Number: SYS-1234567890 UUID: Not Settable Wake-up Type: Power Switch Handle 0x0002 DMI type 2, 8 bytes. Base Board Information Manufacturer: ASUSTeK Computer INC. Product Name: CUV4X-E Version: REV 1.xx Serial Number: xxxxxxxxxxx Handle 0x0003 DMI type 3, 17 bytes. Chassis Information Manufacturer: Chassis Manufacture Type: Tower Lock: Not Present Version: Chassis Version Serial Number: Chassis Serial Number Asset Tag: Asset-1234567890 Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: Unknown OEM Information: 0x00000000 Handle 0x0004 DMI type 4, 32 bytes. Processor Information Socket Designation: PGA 370 Type: Central Processor Family: Celeron Manufacturer: GenuineIntel ID: 8A 06 00 00 FF F9 83 03 Signature: Type 0, Family 6, Model 8, Stepping 10 Flags: FPU (Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model specific registers) PAE (Physical address extension) MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page global enable) MCA (Machine check architecture) CMOV (Conditional move instruction supported) PAT (Page attribute table) PSE-36 (36-bit page size extension) MMX (MMX technology supported) FXSR (Fast floating-point save and restore) SSE (Streaming SIMD extensions) Version: Intel Celeron(TM) Processor Voltage: 1.7 V External Clock: 100 MHz Max Speed: 1200 MHz Current Speed: 1100 MHz Status: Populated, Enabled Upgrade: LIF Socket L1 Cache Handle: 0x000A L2 Cache Handle: 0x000B L3 Cache Handle: Not Provided Handle 0x0005 DMI type 5, 24 bytes. Memory Controller Information Error Detecting Method: None Error Correcting Capabilities: Other Supported Interleave: Unknown Current Interleave: Unknown Maximum Memory Module Size: 1024 MB Maximum Total Memory Size: 4096 MB Supported Speeds: 70 ns 60 ns 50 ns Supported Memory Types: DIMM SDRAM Memory Module Voltage: 3.3 V Associated Memory Slots: 4 0x0006 0x0007 0x0008 0x0009 Enabled Error Correcting Capabilities: Unknown Handle 0x0006 DMI type 6, 12 bytes. Memory Module Information Socket Designation: DIMM 1 Bank Connections: 0 1 Current Speed: Unknown Type: DIMM SDRAM Installed Size: 128 MB (Single-bank Connection) Enabled Size: 128 MB (Single-bank Connection) Error Status: OK Handle 0x0007 DMI type 6, 12 bytes. Memory Module Information Socket Designation: DIMM 2 Bank Connections: 2 3 Current Speed: Unknown Type: DIMM SDRAM Installed Size: 128 MB (Double-bank Connection) Enabled Size: 128 MB (Double-bank Connection) Error Status: OK Handle 0x0008 DMI type 6, 12 bytes. Memory Module Information Socket Designation: DIMM 3 Bank Connections: 4 5 Current Speed: Unknown Type: DIMM SDRAM Installed Size: Not Installed (Single-bank Connection) Enabled Size: Not Installed (Single-bank Connection) Error Status: OK Handle 0x0009 DMI type 6, 12 bytes. Memory Module Information Socket Designation: DIMM 4 Bank Connections: 6 7 Current Speed: Unknown Type: DIMM SDRAM Installed Size: Not Installed (Single-bank Connection) Enabled Size: Not Installed (Single-bank Connection) Error Status: OK Handle 0x000A DMI type 7, 19 bytes. Cache Information Socket Designation: L1 Cache Configuration: Enabled, Not Socketed, Level 1 Operational Mode: Write Back Location: Internal Installed Size: 32 KB Maximum Size: 32 KB Supported SRAM Types: Pipeline Burst Synchronous Installed SRAM Type: Pipeline Burst Synchronous Speed: Unknown Error Correction Type: Unknown System Type: Data Associativity: 4-way Set-associative Handle 0x000B DMI type 7, 19 bytes. Cache Information Socket Designation: L2 Cache Configuration: Enabled, Not Socketed, Level 2 Operational Mode: Write Back Location: Internal Installed Size: 128 KB Maximum Size: 256 KB Supported SRAM Types: Pipeline Burst Synchronous Installed SRAM Type: Pipeline Burst Synchronous Speed: Unknown Error Correction Type: Unknown System Type: Data Associativity: 4-way Set-associative Handle 0x000C DMI type 8, 9 bytes. Port Connector Information Internal Reference Designator: PRIMARY IDE/HDD Internal Connector Type: On Board IDE External Reference Designator: Not Specified External Connector Type: None Port Type: None Handle 0x000D DMI type 8, 9 bytes. Port Connector Information Internal Reference Designator: SECONDARY IDE/HDD Internal Connector Type: On Board IDE External Reference Designator: Not Specified External Connector Type: None Port Type: None Handle 0x000E DMI type 8, 9 bytes. Port Connector Information Internal Reference Designator: FLOPPY Internal Connector Type: On Board Floppy External Reference Designator: Not Specified External Connector Type: None Port Type: None Handle 0x000F DMI type 8, 9 bytes. Port Connector Information Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: USB1 External Connector Type: Access Bus (USB) Port Type: USB Handle 0x0010 DMI type 8, 9 bytes. Port Connector Information Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: USB2 External Connector Type: Access Bus (USB) Port Type: USB Handle 0x0011 DMI type 8, 9 bytes. Port Connector Information Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: PS/2 Keybaord External Connector Type: PS/2 Port Type: Keyboard Port Handle 0x0012 DMI type 8, 9 bytes. Port Connector Information Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: PS/2 Mouse External Connector Type: PS/2 Port Type: Mouse Port Handle 0x0013 DMI type 8, 9 bytes. Port Connector Information Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: Parallel Port External Connector Type: DB-25 female Port Type: Parallel Port ECP/EPP Handle 0x0014 DMI type 8, 9 bytes. Port Connector Information Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: Serial Port External Connector Type: DB-9 male Port Type: Serial Port 16550 Compatible Handle 0x0015 DMI type 8, 9 bytes. Port Connector Information Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: Serial Port 2 External Connector Type: DB-9 male Port Type: Serial Port 16550 Compatible Handle 0x0016 DMI type 8, 9 bytes. Port Connector Information Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: Video Port External Connector Type: Mini Jack (headphones) Port Type: Video Port Handle 0x0017 DMI type 9, 13 bytes. System Slot Information Designation: PCI 1 Type: 32-bit PCI Current Usage: Available Length: Short ID: 1 Characteristics: 5.0 V is provided 3.3 V is provided PME signal is supported Handle 0x0018 DMI type 9, 13 bytes. System Slot Information Designation: PCI 2 Type: 32-bit PCI Current Usage: In Use Length: Short ID: 2 Characteristics: 5.0 V is provided 3.3 V is provided PME signal is supported Handle 0x0019 DMI type 9, 13 bytes. System Slot Information Designation: PCI 3 Type: 32-bit PCI Current Usage: In Use Length: Short ID: 3 Characteristics: 5.0 V is provided 3.3 V is provided PME signal is supported Handle 0x001A DMI type 9, 13 bytes. System Slot Information Designation: PCI 4 Type: 32-bit PCI Current Usage: In Use Length: Short ID: 4 Characteristics: 5.0 V is provided 3.3 V is provided PME signal is supported Handle 0x001B DMI type 9, 13 bytes. System Slot Information Designation: PCI 5 Type: 32-bit PCI Current Usage: Available Length: Short ID: 5 Characteristics: 5.0 V is provided 3.3 V is provided PME signal is supported Handle 0x001C DMI type 9, 13 bytes. System Slot Information Designation: PCI 6 Type: 32-bit PCI Current Usage: Available Length: Short ID: 6 Characteristics: 5.0 V is provided 3.3 V is provided PME signal is supported Handle 0x001D DMI type 9, 13 bytes. System Slot Information Designation: AGP Type: 32-bit PCI Current Usage: In Use Length: Short ID: 7 Characteristics: 3.3 V is provided PME signal is supported Handle 0x001E DMI type 11, 5 bytes. OEM Strings String 1: 0 String 2: 0 Handle 0x001F DMI type 13, 22 bytes. BIOS Language Information Installable Languages: 1 en|US|iso8859-1 Currently Installed Language: en|US|iso8859-1 Handle 0x0020 DMI type 14, 14 bytes. Group Associations Name: Cpu Module Items: 3 0x0004 (Processor) 0x000A (Cache) 0x000B (Cache) Handle 0x0021 DMI type 14, 35 bytes. Group Associations Name: Memory Module Set Items: 10 0x0022 (Physical Memory Array) 0x0023 (Memory Device) 0x0028 (Memory Device Mapped Address) 0x0024 (Memory Device) 0x0029 (Memory Device Mapped Address) 0x0025 (Memory Device) 0x002A (Memory Device Mapped Address) 0x0026 (Memory Device) 0x002B (Memory Device Mapped Address) 0x0027 (Memory Array Mapped Address) Handle 0x0022 DMI type 16, 15 bytes. Physical Memory Array Location: System Board Or Motherboard Use: System Memory Error Correction Type: None Maximum Capacity: 1 GB Error Information Handle: Not Provided Number Of Devices: 4 Handle 0x0023 DMI type 17, 23 bytes. Memory Device Array Handle: 0x0022 Error Information Handle: No Error Total Width: 72 bits Data Width: 64 bits Size: 128 MB Form Factor: DIMM Set: 1 Locator: DIMM 1 Bank Locator: Not Specified Type: DRAM Type Detail: Synchronous Speed: Unknown Handle 0x0024 DMI type 17, 23 bytes. Memory Device Array Handle: 0x0022 Error Information Handle: No Error Total Width: 72 bits Data Width: 64 bits Size: 128 MB Form Factor: DIMM Set: 2 Locator: DIMM 2 Bank Locator: Not Specified Type: DRAM Type Detail: Synchronous Speed: Unknown Handle 0x0025 DMI type 17, 23 bytes. Memory Device Array Handle: 0x0022 Error Information Handle: No Error Total Width: Unknown Data Width: Unknown Size: No Module Installed Form Factor: DIMM Set: 2 Locator: DIMM 3 Bank Locator: Not Specified Type: DRAM Type Detail: Synchronous Speed: Unknown Handle 0x0026 DMI type 17, 23 bytes. Memory Device Array Handle: 0x0022 Error Information Handle: No Error Total Width: Unknown Data Width: Unknown Size: No Module Installed Form Factor: DIMM Set: 2 Locator: DIMM 4 Bank Locator: Not Specified Type: DRAM Type Detail: Synchronous Speed: Unknown Handle 0x0027 DMI type 19, 15 bytes. Memory Array Mapped Address Starting Address: 0x00000000000 Ending Address: 0x040000003FF Range Size: 268435457 kB Physical Array Handle: 0x0022 Partition Width: 0 Handle 0x0028 DMI type 20, 19 bytes. Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x00007FFFFFF Range Size: 128 MB Physical Device Handle: 0x0023 Memory Array Mapped Address Handle: 0x0027 Partition Row Position: 1 Handle 0x0029 DMI type 20, 19 bytes. Memory Device Mapped Address Starting Address: 0x00008000000 Ending Address: 0x0000FFFFFFF Range Size: 128 MB Physical Device Handle: 0x0024 Memory Array Mapped Address Handle: 0x0027 Partition Row Position: 2 Handle 0x002A DMI type 126, 19 bytes. Inactive Handle 0x002B DMI type 126, 19 bytes. Inactive Handle 0x002C DMI type 32, 11 bytes. System Boot Information Status: No errors detected Handle 0x002D DMI type 127, 4 bytes. End Of Table 00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4) Subsystem: Asustek Computer, Inc.: Unknown device 80e7 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00: 06 11 91 06 06 00 10 22 c4 00 00 06 00 00 00 00 10: 08 00 00 fc 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 e7 80 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: fd d8 c8 f6 04 00 10 10 88 00 08 08 0c 10 10 10 60: 0f 2a 00 a0 e6 e6 95 95 41 7c 86 2f 08 6f 00 33 70: c0 88 cc 0c 0e a1 d2 00 01 b4 01 02 00 00 00 02 80: 0f 41 00 00 e0 00 00 00 03 80 f1 0f cc 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 02 c0 20 00 03 02 00 1f 00 00 00 00 6b 02 00 00 b0: 7f 63 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 01 00 00 00 00 00 00 0e 00 00 00 00 00 00 00 00 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- FastB2B- Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00: 06 11 98 85 07 00 30 22 00 00 04 06 00 00 01 00 10: 00 00 00 00 00 00 00 00 00 01 01 00 d0 d0 00 00 20: 00 fa d0 fa f0 fa f0 fb 00 00 00 00 00 00 00 00 30: 00 00 00 00 80 00 00 00 00 00 00 00 00 00 08 00 40: c8 cd 00 44 04 72 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 01 00 02 02 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40) Subsystem: Asustek Computer, Inc.: Unknown device 80e7 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- [disabled] [size=128K] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable+ DSel=0 DScale=1 PME- Capabilities: [e4] PCI-X non-bridge device. Command: DPERE- ERO+ RBC=0 OST=0 Status: Bus=0 Dev=0 Func=0 64bit- 133MHz- SCD- USC-, DC=simple, DMMRBC=2, DMOST=0, DMCRS=0, RSCEM- Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 00: 86 80 0c 10 17 00 30 02 02 00 00 02 08 20 00 00 10: 00 00 80 f9 00 00 00 f9 01 a8 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 12 11 30: 00 00 00 00 dc 00 00 00 00 00 00 00 0a 01 ff 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 01 e4 22 c8 e0: 00 21 00 37 07 f0 02 00 00 00 40 00 00 00 00 00 f0: 05 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00:09.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 30) Subsystem: 3Com Corporation 3C905B Fast Etherlink XL 10/100 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- [disabled] [size=128K] Capabilities: [dc] Power Management version 1 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00: b7 10 55 90 17 00 10 02 30 00 00 02 08 20 00 00 10: 01 a4 00 00 00 00 80 f8 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 b7 10 55 90 30: 00 00 00 00 dc 00 00 00 00 00 00 00 07 01 0a 0a 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 01 00 01 f6 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:0a.0 FireWire (IEEE 1394): Texas Instruments TSB12LV23 IEEE-1394 Controller (prog-if 10 [OHCI]) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- 00: 02 10 42 47 87 00 90 02 5c 00 00 03 08 40 00 00 10: 08 00 00 fb 01 d8 00 00 00 00 00 fa 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 02 10 80 00 30: 00 00 fe fa 50 00 00 00 00 00 00 00 ff 00 08 00 40: 0c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 02 00 10 00 03 02 00 ff 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 From haveblue@us.ibm.com Wed Jul 2 17:56:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 17:56:45 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h630uR2x013011 for ; Wed, 2 Jul 2003 17:56:34 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h630uKXq147674; Wed, 2 Jul 2003 20:56:20 -0400 Received: from DYN318089.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h630uIqO253254; Wed, 2 Jul 2003 20:56:18 -0400 Subject: impressive throughput on 2.5.73 From: Dave Hansen To: netdev@oss.sgi.com Cc: Scott Feldman , Nivedita Singhvi Content-Type: text/plain Organization: Message-Id: <1057193766.31286.843.camel@nighthawk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 02 Jul 2003 17:56:07 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 3731 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: haveblue@us.ibm.com Precedence: bulk X-list: netdev I run a little script to load up a gigabit ethernet link between two of my machines: an 8-way PIII web server, and a 4-way PIII client. Both client and server have e1000s. The script fetches a bunch of fairly big files via http from the server, using apache. I'm impressed that it can fill just about the entire gigabit pipe, while using less than 1 of the server's CPUs. 176 requests/sec - 110.0 MB/second - 0.6 MB/request Server CPU breakdown. 2% system 7% user 91% idle I'm not using any interrupt mitigation, so I'm still at ~9k interrupts/sec. I'll try NAPI next. server profile: 197212 total 0.1159 175783 poll_idle 2441.4306 1474 alloc_skb 6.8241 1281 skb_release_data 8.6554 1202 skb_clone 3.7563 1038 do_tcp_sendpages 0.3655 998 e1000_clean_tx_irq 2.1886 974 e1000_xmit_frame 0.5148 841 tcp_transmit_skb 0.5729 827 Letext 2.0675 791 __kmalloc 6.3790 739 ip_queue_xmit 0.6415 629 ip_finish_output 1.4976 583 tcp_write_xmit 0.7836 571 tcp_v4_rcv 0.2896 422 schedule 0.2733 417 e1000_intr 3.7232 403 tcp_clean_rtx_queue 0.5140 399 __kfree_skb 2.1685 353 kfree 3.6771 337 kmem_cache_free 4.4342 309 e1000_clean_rx_irq 0.3053 291 find_get_page 6.0625 284 do_softirq 1.4200 246 eth_type_trans 1.4643 233 dev_queue_xmit 0.4380 226 __wake_up 5.1364 216 ip_rcv 0.2093 202 sock_wfree 3.3667 202 memcpy 5.0500 client profile: 33363 total 0.0196 9575 poll_idle 132.9861 5099 __copy_user_intel 32.6859 3307 schedule 2.1418 1753 __wake_up 39.8409 667 tcp_v4_rcv 0.3382 577 pipe_write 0.7970 510 __down_wq 1.7708 488 alloc_skb 2.2593 476 tcp_recvmsg 0.2216 457 tcp_rcv_established 0.2746 457 __kfree_skb 2.4837 405 dnotify_parent 4.5000 382 pipe_read 0.7290 368 system_call 8.3636 350 kill_fasync 7.0000 341 current_kernel_time 5.0147 299 __kmalloc 2.4113 280 ip_rcv 0.2713 252 eth_type_trans 1.5000 245 skb_release_data 1.6554 233 ip_queue_xmit 0.2023 232 kfree 2.4167 228 e1000_clean_rx_irq 0.2253 210 pipe_wait 1.3816 205 e1000_clean_tx_irq 0.4496 200 tcp_transmit_skb 0.1362 199 e1000_xmit_frame 0.1052 -- Dave Hansen haveblue@us.ibm.com From niv@us.ibm.com Wed Jul 2 20:01:43 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 20:01:46 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h6331a2x014325 for ; Wed, 2 Jul 2003 20:01:42 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h6331R8w246212; Wed, 2 Jul 2003 23:01:28 -0400 Received: from us.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6331QsH179690; Wed, 2 Jul 2003 21:01:27 -0600 Message-ID: <3F039BE1.2080008@us.ibm.com> Date: Wed, 02 Jul 2003 19:58:41 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Hansen CC: netdev@oss.sgi.com, Scott Feldman Subject: Re: impressive throughput on 2.5.73 References: <1057193766.31286.843.camel@nighthawk> In-Reply-To: <1057193766.31286.843.camel@nighthawk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3733 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Dave Hansen wrote: > 176 requests/sec - 110.0 MB/second - 0.6 MB/request > > Server CPU breakdown. > 2% system > 7% user > 91% idle > > client profile: > 33363 total 0.0196 > 9575 poll_idle 132.9861 > 5099 __copy_user_intel 32.6859 > 3307 schedule 2.1418 > 1753 __wake_up 39.8409 > 667 tcp_v4_rcv 0.3382 Nice numbers :). In addition to NAPI, would be nice to stick in more adapters. Any idea why __wake_up should be so expensive on the client side? thanks, Nivedita From haveblue@us.ibm.com Wed Jul 2 20:21:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 20:21:22 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h633LB2x016492 for ; Wed, 2 Jul 2003 20:21:18 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h633L4Xq143078; Wed, 2 Jul 2003 23:21:04 -0400 Received: from nighthawk.sr71.net (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h633L241074244; Wed, 2 Jul 2003 23:21:03 -0400 Subject: Re: impressive throughput on 2.5.73 From: Dave Hansen To: Nivedita Singhvi Cc: netdev@oss.sgi.com, Scott Feldman In-Reply-To: <3F039BE1.2080008@us.ibm.com> References: <1057193766.31286.843.camel@nighthawk> <3F039BE1.2080008@us.ibm.com> Content-Type: text/plain Organization: Message-Id: <1057202451.2916.36.camel@nighthawk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 02 Jul 2003 20:20:52 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 3734 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: haveblue@us.ibm.com Precedence: bulk X-list: netdev On Wed, 2003-07-02 at 19:58, Nivedita Singhvi wrote: > Nice numbers :). In addition to NAPI, would be nice to > stick in more adapters. Any idea why __wake_up should be > so expensive on the client side? NAPI seems to degrade throughput down to ~80MB/sec, but the interrupt rate doesn't change. I'm going to put some debugging in and makes sure that it's kicking in properly. -- Dave Hansen haveblue@us.ibm.com From shibu_lkml@yahoo.com Wed Jul 2 20:16:11 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 20:27:14 -0700 (PDT) Received: from web20704.mail.yahoo.com (web20704.mail.yahoo.com [216.136.226.177]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h633GA2x016453 for ; Wed, 2 Jul 2003 20:16:11 -0700 Message-ID: <20030703031610.79050.qmail@web20704.mail.yahoo.com> Received: from [202.54.26.201] by web20704.mail.yahoo.com via HTTP; Wed, 02 Jul 2003 20:16:10 PDT Date: Wed, 2 Jul 2003 20:16:10 -0700 (PDT) From: Shibu LKML Subject: Disconnecting a connected UDP socket To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-572335396-1057202170=:79043" X-archive-position: 3735 X-Approved-By: ralf@linux-mips.org X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shibu_lkml@yahoo.com Precedence: bulk X-list: netdev --0-572335396-1057202170=:79043 Content-Type: text/plain; charset=us-ascii Hi, I am wondering if Linux supports disconnecting a connected UDP socket. The manpage for connect lists it in the BUGS section. It says disconnect is still not supported. I was wondering if it involves more than adding the following lines to udp_connect in udp.c if (usin->sin_family == AF_UNSPEC) return udp_disconnect(sk, 0); (just above sk_dst_reset(sk)) Will this fix the problem for IPV4 stuff? Regards Shibu --------------------------------- Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! --0-572335396-1057202170=:79043 Content-Type: text/html; charset=us-ascii
Hi,
 
I am wondering if Linux supports disconnecting a connected UDP socket. The manpage for connect lists it in the BUGS section. It says disconnect is still not supported. I was wondering if it involves more than adding the following lines to udp_connect in udp.c
 
if (usin->sin_family == AF_UNSPEC)
  return udp_disconnect(sk, 0);
(just  above sk_dst_reset(sk))
 
Will this fix the problem for IPV4 stuff?
 
 
Regards
Shibu
 

Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month! --0-572335396-1057202170=:79043-- From haveblue@us.ibm.com Wed Jul 2 21:50:42 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Jul 2003 21:50:50 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.9/8.12.9) with SMTP id h634of2x017532 for ; Wed, 2 Jul 2003 21:50:41 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34