From shmulik.hen@intel.com Tue Apr 1 08:10:03 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Apr 2003 08:10:14 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h31G9Lq9020029 for ; Tue, 1 Apr 2003 08:10:02 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h31G5AJ14946 for ; Tue, 1 Apr 2003 16:05:10 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h31GBuB25127 for ; Tue, 1 Apr 2003 16:11:56 GMT Received: from hasmsx17.iil.intel.com ([143.185.63.203]) by hasmsxvs01.iil.intel.com (NAVGW 2.5.2.11) with SMTP id M2003040119142716704 ; Tue, 01 Apr 2003 19:14:27 +0300 Received: by hasmsx17.iil.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Apr 2003 19:09:13 +0300 Message-ID: From: "Hen, Shmulik" To: "David S. Miller" Cc: bonding-devel@lists.sourceforge.net, bonding-announce@lists.sourceforge.net, linux-net@vger.kernel.org, netdev@oss.sgi.com, jgarzik@pobox.com Subject: RE: [Bonding][patch] Adding Transmit load balancing mode to bondi ng Date: Tue, 1 Apr 2003 19:09:09 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2115 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 We haven't experimented with layer 4 load balancing in the past. I guess this is because of the big overhead of parsing the skb for the necessary data, but also because of the risk of dealing with IP fragmentation, large send issues, encryption and all kinds of off-loadings. Shmulik. > -----Original Message----- > From: David S. Miller [mailto:davem@redhat.com] > Sent: Thursday, March 27, 2003 6:06 PM > To: Hen, Shmulik > Cc: bonding-devel@lists.sourceforge.net; > bonding-announce@lists.sourceforge.net; > linux-net@vger.kernel.org; netdev@oss.sgi.com; > linux-kernel@vger.kernel.org; jgarzik@pobox.com > Subject: Re: [Bonding][patch] Adding Transmit load balancing > mode to bonding > > > From: shmulik.hen@intel.com > Date: Thu, 27 Mar 2003 17:38:02 +0200 (IST) > > Balancing is connection oriented (e.g. by IPv4 destination address) > so packet order is always kept. > > You could also key off of the destination/source port as well for > UDP/TCP/SCTP. Have you experimented with this? > From rask@sygehus.dk Tue Apr 1 08:49:43 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Apr 2003 08:49:49 -0800 (PST) Received: from cicero0.cybercity.dk (cicero0.cybercity.dk [212.242.40.52]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h31Gnfq9020629 for ; Tue, 1 Apr 2003 08:49:43 -0800 Received: from user3.cybercity.dk (fxp0.user3.ip.cybercity.dk [212.242.41.36]) by cicero0.cybercity.dk (Postfix) with ESMTP id B2D4A102A05; Tue, 1 Apr 2003 18:49:39 +0200 (CEST) Received: from webmail.cybercity.dk (webmail.cybercity.dk [212.242.40.37]) by user3.cybercity.dk (Postfix) with SMTP id E66511FB; Tue, 1 Apr 2003 18:49:38 +0200 (CEST) Reply-To: rask@sygehus.dk From: rask@sygehus.dk (Rask Ingemann Lambertsen) To: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Is a driver allowed to modify dev->flags? Date: Tue, 1 Apr 2003 18:49:39 +0200 Message-Id: <3e89c32348ce76.94538914@not right> X-Authenticated-IP: [152.95.52.86] X-Sender: ccc94453@vip.cybercity.dk X-Mailer: Cybercity Webmail 1.06 (http://webmail.cybercity.dk/) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2116 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rask@sygehus.dk Precedence: bulk X-list: netdev Hi. Is a network device driver allowed to modify dev->flags? For example: if (dev->flags & IFF_ALLMULTI) dev->flags |= IFF_PROMISC; I've found it to cause the IFF_PROMISC flag to stick when using "tcpdump -p", which to my surprice sets the IFF_ALLMULTI flag. Regards, Rask Ingemann Lambertsen From greearb@candelatech.com Tue Apr 1 08:59:57 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Apr 2003 09:00:00 -0800 (PST) Received: from grok.yi.org (IDENT:n3vqeOdPrL+AtFZojQViyJ8x9LBnkonw@dhcp93-dsl-usw3.w-link.net [206.129.84.93]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h31GxGq9021029 for ; Tue, 1 Apr 2003 08:59:56 -0800 Received: from candelatech.com (IDENT:vgwWu11u12MF+05vNe3mavi3M594w8qh@localhost.localdomain [127.0.0.1]) by grok.yi.org (8.11.6/8.11.6) with ESMTP id h31Gw7J15384; Tue, 1 Apr 2003 08:58:25 -0800 Message-ID: <3E89C51E.1060700@candelatech.com> Date: Tue, 01 Apr 2003 08:58:06 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rask@sygehus.dk CC: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Is a driver allowed to modify dev->flags? References: <3e89c32348ce76.94538914@not right> In-Reply-To: <3e89c32348ce76.94538914@not right> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2117 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 Rask Ingemann Lambertsen wrote: > Hi. > > Is a network device driver allowed to modify dev->flags? For example: > > if (dev->flags & IFF_ALLMULTI) > dev->flags |= IFF_PROMISC; > > I've found it to cause the IFF_PROMISC flag to stick when using "tcpdump -p", which to my surprice sets the IFF_ALLMULTI flag. > > Regards, > Rask Ingemann Lambertsen > > You are supposed to increment the promisc requestors. I think something like this: dev_set_promiscuity(dev, 1); -- Ben Greear President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear From rask@sygehus.dk Tue Apr 1 09:01:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Apr 2003 09:01:43 -0800 (PST) Received: from cicero0.cybercity.dk (cicero0.cybercity.dk [212.242.40.52]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h31H0xq9021360 for ; Tue, 1 Apr 2003 09:01:40 -0800 Received: from user3.cybercity.dk (fxp0.user3.ip.cybercity.dk [212.242.41.36]) by cicero0.cybercity.dk (Postfix) with ESMTP id B3036102A78; Tue, 1 Apr 2003 19:00:58 +0200 (CEST) Received: from webmail.cybercity.dk (webmail.cybercity.dk [212.242.40.37]) by user3.cybercity.dk (Postfix) with SMTP id 2AB0B2CF; Tue, 1 Apr 2003 19:00:58 +0200 (CEST) Reply-To: rask@sygehus.dk From: rask@sygehus.dk (Rask Ingemann Lambertsen) To: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: net_device_stats questions Date: Tue, 1 Apr 2003 19:00:58 +0200 Message-Id: <3e89c5ca40b872.57198744@not right> X-Authenticated-IP: [152.95.52.86] X-Sender: ccc94453@vip.cybercity.dk X-Mailer: Cybercity Webmail 1.06 (http://webmail.cybercity.dk/) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2118 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rask@sygehus.dk Precedence: bulk X-list: netdev Hi. When updating net_device_stats.tx_bytes, should I just add skb->len (like e.g. tulip does) or add skb->len plus any padding (like e.g. 3c59x does)? Let's say a TX heartbeat error occurs. Am I then supposed to update both net_device_stats.tx_errors and net_device_stats.tx_heartbeat_errors or just net_device_stats.tx_heartbeat_errors? Which events should cause an update of net_device_stats.tx_aborted? Regards, Rask Ingemann Lambertsen From davem@redhat.com Tue Apr 1 09:03:45 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Apr 2003 09:03:52 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h31H34q9021729 for ; Tue, 1 Apr 2003 09:03:44 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id IAA18659; Tue, 1 Apr 2003 08:58:18 -0800 Date: Tue, 01 Apr 2003 08:58:17 -0800 (PST) Message-Id: <20030401.085817.56963537.davem@redhat.com> To: shmulik.hen@intel.com Cc: bonding-devel@lists.sourceforge.net, bonding-announce@lists.sourceforge.net, linux-net@vger.kernel.org, netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [Bonding][patch] Adding Transmit load balancing mode to bondi ng From: "David S. Miller" In-Reply-To: References: X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2119 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: "Hen, Shmulik" Date: Tue, 1 Apr 2003 19:09:09 +0300 We haven't experimented with layer 4 load balancing in the past. I guess this is because of the big overhead of parsing the skb for the necessary data, but also because of the risk of dealing with IP fragmentation, large send issues, encryption and all kinds of off-loadings. In the modern internet, a fragmented TCP packet is nearly a bug. And if it's encrypted, you will never see the TCP headers to begin with. Finally, there are no "large send" issues, the TCP port information will always be in the front of the packet. I brought this up because it is very clear to me that various load-balancing daemons distributed by other gigabit card vendors are keying on the connection information in TCP packets. So someone thinks it is worthwhile :-) From rask@sygehus.dk Tue Apr 1 09:27:01 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Apr 2003 09:27:03 -0800 (PST) Received: from cicero0.cybercity.dk (cicero0.cybercity.dk [212.242.40.52]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h31HQxq9022331 for ; Tue, 1 Apr 2003 09:27:00 -0800 Received: from user4.cybercity.dk (fxp0.user4.ip.cybercity.dk [212.242.41.50]) by cicero0.cybercity.dk (Postfix) with ESMTP id 94979102931; Tue, 1 Apr 2003 19:26:58 +0200 (CEST) Received: from webmail.cybercity.dk (webmail.cybercity.dk [212.242.40.37]) by user4.cybercity.dk (Postfix) with SMTP id D9AC454BF; Tue, 1 Apr 2003 19:26:57 +0200 (CEST) Reply-To: rask@sygehus.dk From: rask@sygehus.dk (Rask Ingemann Lambertsen) To: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Must dev->set_multicast_list() complete before returning? Date: Tue, 1 Apr 2003 19:26:58 +0200 Message-Id: <3e89cbe235cd78.41777977@not right> X-Authenticated-IP: [152.95.52.86] X-Sender: ccc94453@vip.cybercity.dk X-Mailer: Cybercity Webmail 1.06 (http://webmail.cybercity.dk/) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2121 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rask@sygehus.dk Precedence: bulk X-list: netdev Hi. Must dev->set_multicast_list() complete the configuration of a network device before returning? Regards, Rask Ingemann Lambertsen From becker@scyld.com Tue Apr 1 09:26:27 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Apr 2003 09:26:30 -0800 (PST) Received: from beohost.scyld.com (dsl093-058-082.blt1.dsl.speakeasy.net [66.93.58.82]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h31HQQq9022270 for ; Tue, 1 Apr 2003 09:26:27 -0800 Received: from localhost (becker@localhost) by beohost.scyld.com (8.11.6/8.11.6) with ESMTP id h31HQri09692; Tue, 1 Apr 2003 12:26:54 -0500 Date: Tue, 1 Apr 2003 12:26:53 -0500 (EST) From: Donald Becker To: Rask Ingemann Lambertsen cc: linux-net@vger.kernel.org, Subject: Re: Is a driver allowed to modify dev->flags? In-Reply-To: <3e89c32348ce76.94538914@not right> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2120 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: becker@scyld.com Precedence: bulk X-list: netdev On Tue, 1 Apr 2003, Rask Ingemann Lambertsen wrote: > Is a network device driver allowed to modify dev->flags? For example: > > if (dev->flags & IFF_ALLMULTI) > dev->flags |= IFF_PROMISC; You must be looking at the atp.c driver, or a driver that cribbed from it. (Is anyone still running a parallel port Ethernet device?!) Alan Cox added this code to atp.c because the chip doesn't have a reasonable multicast filter. The only way to receive all multicast traffic was to turn on promiscuous mode. But that caused a problem with some parts of the protocol stack were passed traffic not intended for the local host. A better solution (which is usually easier to see later) is to have the driver do the trivial final packet filtering itself. > I've found it to cause the IFF_PROMISC flag to stick when using > "tcpdump -p", which to my surprice sets the IFF_ALLMULTI flag. Which driver are you using? -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From blueflux@koffein.net Tue Apr 1 09:47:10 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Apr 2003 09:47:15 -0800 (PST) Received: from laptop1.agatha ([195.163.42.244]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h31Hl8q9023516 for ; Tue, 1 Apr 2003 09:47:09 -0800 Received: from localhost (blueflux@localhost) by laptop1.agatha (8.11.6/8.11.6) with ESMTP id h31HXE622646; Tue, 1 Apr 2003 19:33:17 +0200 X-Authentication-Warning: laptop1.agatha: blueflux owned process doing -bs Date: Tue, 1 Apr 2003 19:33:13 +0200 (CEST) From: Oskar Andreasson X-X-Sender: blueflux@laptop1.agatha To: "David S. Miller" , "Alexey N. Kuznetsov" cc: netdev@oss.sgi.com Subject: [PATCH][RESEND] Update of tcp_syncookies explanation Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463810815-689177628-1049217616=:22637" Content-ID: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2122 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: blueflux@koffein.net Precedence: bulk X-list: netdev This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1463810815-689177628-1049217616=:22637 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Hi David, Alexey, et al. This is a patch that fixes/updates the tcp_syncookies explanation in the linux/Documentation/networking/ip-sysctl.txt document. Basically it reduces some of the "big red lights" set up about using this specific feature, and instead explains in more detail why the user should be careful about using the syncookies option. If anyone has any objections against this patch, please tell me so, with an explanation of why! [slightly off-topic explanation] It seems I got caught in the crossfire between two camps when I started writing the ipsysctl-tutorial at ipsysctl-tutorial.frozentux.net and at first I received some rather nasty mails about not warning enough about the syncookies option, so I changed it, at which point I received some more poison from the other side for warning about the option at all. Hence, my decision has been to walk somewhere on the borderline by simply explaining the option, what it does, how it works, and what the cons are, without taking up too much space in the kernelspace. I believe this is what would be best for the kernel documentation as well. If anyone disagrees, see above, send me a mail explaining why you disagree. Thanks! ---- Oskar Andreasson http://www.frozentux.net http://iptables-tutorial.frozentux.net http://ipsysctl-tutorial.frozentux.net mailto:blueflux@koffein.net ---1463810815-689177628-1049217616=:22637 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="2.4.19.docs.net.ip-sysctl.txt-2.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="2.4.19.docs.net.ip-sysctl.txt-2.patch" ZGlmZiAtdXIgbGludXgtMi40LjE5L0RvY3VtZW50YXRpb24vbmV0d29ya2lu Zy9pcC1zeXNjdGwudHh0IGxpbnV4LTIuNC4xOS5uZXcvRG9jdW1lbnRhdGlv bi9uZXR3b3JraW5nL2lwLXN5c2N0bC50eHQNCi0tLSBsaW51eC0yLjQuMTkv RG9jdW1lbnRhdGlvbi9uZXR3b3JraW5nL2lwLXN5c2N0bC50eHQJU2F0IEF1 ZyAgMyAwMjozOTo0MiAyMDAyDQorKysgbGludXgtMi40LjE5Lm5ldy9Eb2N1 bWVudGF0aW9uL25ldHdvcmtpbmcvaXAtc3lzY3RsLnR4dAlTdW4gTm92IDEw IDE4OjEzOjI2IDIwMDINCkBAIC0xNjIsNyArMTYyLDcgQEANCiAJb3ZlcmZs b3dzLiBUaGlzIGlzIHRvIHByZXZlbnQgYWdhaW5zdCB0aGUgY29tbW9uICdz eW4gZmxvb2QgYXR0YWNrJw0KIAlEZWZhdWx0OiBGQUxTRQ0KIA0KLQlOb3Rl LCB0aGF0IHN5bmNvb2tpZXMgaXMgZmFsbGJhY2sgZmFjaWxpdHkuDQorCU5v dGUsIHRoYXQgc3luY29va2llcyBpcyBhIGZhbGxiYWNrIGZhY2lsaXR5Lg0K IAlJdCBNVVNUIE5PVCBiZSB1c2VkIHRvIGhlbHAgaGlnaGx5IGxvYWRlZCBz ZXJ2ZXJzIHRvIHN0YW5kDQogCWFnYWluc3QgbGVnYWwgY29ubmVjdGlvbiBy YXRlLiBJZiB5b3Ugc2VlIHN5bmZsb29kIHdhcm5pbmdzDQogCWluIHlvdXIg bG9ncywgYnV0IGludmVzdGlnYXRpb24Jc2hvd3MgdGhhdCB0aGV5IG9jY3Vy DQpAQCAtMTcwLDEyICsxNzAsMTggQEANCiAJYW5vdGhlciBwYXJhbWV0ZXJz IHVudGlsIHRoaXMgd2FybmluZyBkaXNhcHBlYXIuDQogCVNlZTogdGNwX21h eF9zeW5fYmFja2xvZywgdGNwX3N5bmFja19yZXRyaWVzLCB0Y3BfYWJvcnRf b25fb3ZlcmZsb3cuDQogDQotCXN5bmNvb2tpZXMgc2VyaW91c2x5IHZpb2xh dGUgVENQIHByb3RvY29sLCBkbyBub3QgYWxsb3cNCi0JdG8gdXNlIFRDUCBl eHRlbnNpb25zLCBjYW4gcmVzdWx0IGluIHNlcmlvdXMgZGVncmFkYXRpb24N Ci0Jb2Ygc29tZSBzZXJ2aWNlcyAoZi5lLiBTTVRQIHJlbGF5aW5nKSwgdmlz aWJsZSBub3QgYnkgeW91LA0KLQlidXQgeW91ciBjbGllbnRzIGFuZCByZWxh eXMsIGNvbnRhY3RpbmcgeW91LiBXaGlsZSB5b3Ugc2VlDQotCXN5bmZsb29k IHdhcm5pbmdzIGluIGxvZ3Mgbm90IGJlaW5nIHJlYWxseSBmbG9vZGVkLCB5 b3VyIHNlcnZlcg0KLQlpcyBzZXJpb3VzbHkgbWlzY29uZmlndXJlZC4NCisJ VGhlIHRjcF9zeW5jb29raWVzIG9wdGlvbiBtZWFucyB0aGF0IHdoZW4gdGhl IG1hY2hpbmUgaGFzIG1vcmUgdGhhbiANCisJdGNwX21heF9zeW5fYmFja2xv ZyBTWU4gcGFja2V0cyBpbiB0aGUgcXVldWUsIGl0IHdpbGwgcmV2ZXJ0IHRv IA0KKwlzZW5kaW5nIG91dCBTWU4gY29va2llcy4gdGNwX3N5bmNvb2tpZXMg ZGVwZW5kcyBvbiBhIHNwZWNpZmljYWxseSANCisJZ3JhZnRlZCBUQ1AgU2Vx dWVuY2UgbnVtYmVyLCB3aGljaCB0aGUgU1lOIGZsb29kZXIgbXVzdCBndWVz cyB0aGUgDQorCWNvcnJlY3QgbnVtYmVyIG9mLCB1bmxlc3MgaGUgaXMgYWN0 dWFsbHkgcmVjZWl2aW5nIHRoZSBTWU4vQUNLIHRvDQorCWhpbXNlbGYuIA0K Kw0KKwlXaGVuIFNZTiBjb29raWVzIGFyZSB1c2VkLCBhbGwgbmV3bHkgb3Bl bmVkIGNvbm5lY3Rpb25zIHdpbGwgYmUgdW5hYmxlDQorCXRvIHVzZSBhbnkg YWR2YW5jZWQgZmVhdHVyZXMgbGlrZSBFQ04sIFNBQ0sgb3IgVGltZXN0YW1w cy4gVGhpcyBtYXkgDQorCXJlc3VsdCBpbiBzZXJpb3VzIGRlZ3JhZGF0aW9u IG9mIHNvbWUgc2VydmljZXMsIGFuZCBpZiB5b3Ugc2VlIA0KKwlzeW5mbG9v ZCB3YXJuaW5ncyBpbiB5b3VyIGxvZ3MsIGJ1dCB5b3UgYXJlIG5vdCBiZWlu ZyBmbG9vZGVkLCB5b3VyIA0KKwlzZXJ2ZXIgbWF5IGJlIG1pc2NvbmZpZ3Vy ZWQuDQogDQogdGNwX3N0ZHVyZyAtIEJPT0xFQU4NCiAJVXNlIHRoZSBIb3N0 IHJlcXVpcmVtZW50cyBpbnRlcnByZXRhdGlvbiBvZiB0aGUgVENQIHVyZyBw b2ludGVyIGZpZWxkLg0K ---1463810815-689177628-1049217616=:22637-- From scott.feldman@intel.com Tue Apr 1 09:48:18 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Apr 2003 09:48:21 -0800 (PST) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h31HmIq9023764 for ; Tue, 1 Apr 2003 09:48:18 -0800 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h31HfUn22630 for ; Tue, 1 Apr 2003 17:41:30 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by talaria.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h31HnYd14935 for ; Tue, 1 Apr 2003 17:49:34 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003040109513116460 ; Tue, 01 Apr 2003 09:51:32 -0800 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Apr 2003 09:48:15 -0800 Message-ID: From: "Feldman, Scott" To: Robert Olsson , Jason Lunz Cc: Jeff Garzik , netdev@oss.sgi.com Subject: RE: [Fwd: [E1000] NAPI re-insertion w/ changes] Date: Tue, 1 Apr 2003 09:47:55 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) content-class: urn:content-classes:message Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2123 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 > A better approximation I think but probably not the last... Thanks for you help guys! I broke NAPI (don't hate me) and then went on vacation, so I apologize for not responding sooner. I like what you've come up with here, so I'll turn the patch around for Jeff to update 2.5 e1000. > + e1000_clean_tx_irq(adapter); > + e1000_clean_rx_irq(adapter, &work_done, work_to_do); Just curious, why give priority to Tx over Rx? -scott From davem@redhat.com Tue Apr 1 09:52:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Apr 2003 09:52:25 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h31HqMq9024220 for ; Tue, 1 Apr 2003 09:52:22 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id JAA18765; Tue, 1 Apr 2003 09:47:26 -0800 Date: Tue, 01 Apr 2003 09:47:25 -0800 (PST) Message-Id: <20030401.094725.01304107.davem@redhat.com> To: blueflux@koffein.net Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: [PATCH][RESEND] Update of tcp_syncookies explanation From: "David S. Miller" In-Reply-To: References: X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2124 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: Oskar Andreasson Date: Tue, 1 Apr 2003 19:33:13 +0200 (CEST) If anyone has any objections against this patch, please tell me so, with an explanation of why! You didn't explain how TCP syncookies "seriously violates the TCP protocol" yet you choose to remove that statement written by Alexey. Either retain Alexey's statement (because it's true) or replace it with proper text. I'm not going into the details of how syncookies violates the TCP protocol here, that has been hashed out many times on netdev and linux-net years in the past, so I direct people to search up such discussions instead of starting up yet another flame war here about the topic. Thanks. From rask@sygehus.dk Tue Apr 1 10:08:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Apr 2003 10:08:25 -0800 (PST) Received: from cicero0.cybercity.dk (cicero0.cybercity.dk [212.242.40.52]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h31I7Vq9024687 for ; Tue, 1 Apr 2003 10:08:12 -0800 Received: from user2.cybercity.dk (fxp0.user2.ip.cybercity.dk [212.242.41.35]) by cicero0.cybercity.dk (Postfix) with ESMTP id B1CBC102A4D; Tue, 1 Apr 2003 19:40:30 +0200 (CEST) Received: from webmail.cybercity.dk (webmail.cybercity.dk [212.242.40.37]) by user2.cybercity.dk (Postfix) with SMTP id 535B054D2; Tue, 1 Apr 2003 19:40:30 +0200 (CEST) Reply-To: rask@sygehus.dk From: rask@sygehus.dk (Rask Ingemann Lambertsen) To: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Is a driver allowed to modify dev->flags? Date: Tue, 1 Apr 2003 19:40:30 +0200 Message-Id: <3e89cf0e623458.50320081@not right> References: X-Authenticated-IP: [152.95.52.86] X-Sender: ccc94453@vip.cybercity.dk X-Mailer: Cybercity Webmail 1.06 (http://webmail.cybercity.dk/) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2125 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rask@sygehus.dk Precedence: bulk X-list: netdev Donald Becker wrote: > On Tue, 1 Apr 2003, Rask Ingemann Lambertsen wrote: > > > Is a network device driver allowed to modify dev->flags? For example: > > > > if (dev->flags & IFF_ALLMULTI) > > dev->flags |= IFF_PROMISC; > > You must be looking at the atp.c driver, or a driver that cribbed from > it. (Is anyone still running a parallel port Ethernet device?!) No, but I've seen such code in other Ethernet drivers and adopted it for my NE3200 driver. > > I've found it to cause the IFF_PROMISC flag to stick when using > > "tcpdump -p", which to my surprice sets the IFF_ALLMULTI flag. > > Which driver are you using? My experimental NE3200 driver, linux 2.4.20 and tcpdump from Redhat 7.3. Regards, Rask Ingemann Lambertsen From Robert.Olsson@data.slu.se Tue Apr 1 10:58:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Apr 2003 10:58:47 -0800 (PST) Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h31Iw3oJ026244 for ; Tue, 1 Apr 2003 10:58:44 -0800 Received: (from robert@localhost) by robur.slu.se (8.9.3p2/8.9.3) id UAA11217; Tue, 1 Apr 2003 20:57:24 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16009.57620.391630.720667@robur.slu.se> Date: Tue, 1 Apr 2003 20:57:24 +0200 To: "Feldman, Scott" Cc: Robert Olsson , Jason Lunz , Jeff Garzik , netdev@oss.sgi.com Subject: RE: [Fwd: [E1000] NAPI re-insertion w/ changes] In-Reply-To: References: X-Mailer: VM 6.92 under Emacs 19.34.1 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2127 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 1048 Lines: 33 Feldman, Scott writes: > Thanks for you help guys! I broke NAPI (don't hate me) and then went on > vacation, so I apologize for not responding sooner. I like what you've > come up with here, so I'll turn the patch around for Jeff to update 2.5 > e1000. > > > + e1000_clean_tx_irq(adapter); > > + e1000_clean_rx_irq(adapter, &work_done, work_to_do); > > Just curious, why give priority to Tx over Rx? Hello! Honestly not too much thinking... well we can always argue by having Rx last we get more packets per poll. Yes we should test the other way around. Also still some concern by having the watchdog kicked in e1000_intr wouldn't e1000_clean feel better? It would also be interesting to see what happens if we remove the flush when enable interrupts in e1000_clean? I've tested the patch that removes some of the PCI-accesses. I think I sent you some version of it. Anyway it seems to have some effects. If Jason has time we will get some numbers from his instrument/setup. Cheers. --ro From scott.feldman@intel.com Tue Apr 1 11:14:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Apr 2003 11:14:45 -0800 (PST) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h31JE0oJ026702 for ; Tue, 1 Apr 2003 11:14:40 -0800 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h31JALN09521 for ; Tue, 1 Apr 2003 19:10:21 GMT Received: from fmsmsxv040-1.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by talaria.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h31JFGc04887 for ; Tue, 1 Apr 2003 19:15:16 GMT Received: from FMSMSX016.fm.intel.com ([132.233.42.195]) by fmsmsxv040-1.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003040111141027149 ; Tue, 01 Apr 2003 11:14:10 -0800 Received: by fmsmsx016.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Apr 2003 11:13:57 -0800 Message-ID: From: "Feldman, Scott" To: Robert Olsson Cc: Jason Lunz , Jeff Garzik , netdev@oss.sgi.com Subject: RE: [Fwd: [E1000] NAPI re-insertion w/ changes] Date: Tue, 1 Apr 2003 11:13:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2128 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 Content-Length: 742 Lines: 21 > Also still some concern by having the watchdog kicked in e1000_intr > wouldn't e1000_clean feel better? e1000_intr feels better to me in keeping the clean-up work separate from managing link status change (hopefully an infrequent event :). Do you see any problems? > It would also be interesting to see what happens if we > remove the flush when enable interrupts in e1000_clean? Ya, that read hurts, which was part of the motivation to get rid of the disable/enables altogether. > I've tested the patch that removes some of the PCI-accesses. > I think I sent you some version of it. Anyway it seems to > have some effects. If Jason has > time we will get some numbers from his instrument/setup. Ok, let's see. -scott From linux-netdev@gmane.org Tue Apr 1 11:42:03 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Apr 2003 11:42:50 -0800 (PST) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h31JfLoJ029102 for ; Tue, 1 Apr 2003 11:42:03 -0800 Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 190RcV-0007h3-00 for ; Tue, 01 Apr 2003 21:40:31 +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 190RLi-0006Lj-00 for ; Tue, 01 Apr 2003 21:23:10 +0200 From: Jason Lunz Subject: Re: [Fwd: [E1000] NAPI re-insertion w/ changes] Date: Tue, 1 Apr 2003 19:23:10 +0000 (UTC) Organization: PBR Streetgang Message-ID: References: X-Complaints-To: usenet@main.gmane.org User-Agent: slrn/0.9.7.4 (Linux) X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2129 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lunz@reflexsecurity.com Precedence: bulk X-list: netdev Content-Length: 462 Lines: 14 scott.feldman@intel.com said: >> I've tested the patch that removes some of the PCI-accesses. I >> think I sent you some version of it. Anyway it seems to have some >> effects. If Jason has time we will get some numbers from his >> instrument/setup. > > Ok, let's see. It works. Reducing PCI accessess gives a measurable improvement. I'll post plots later today. -- Jason Lunz Reflex Security lunz@reflexsecurity.com http://www.reflexsecurity.com/ From Robert.Olsson@data.slu.se Tue Apr 1 11:44:40 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Apr 2003 11:44:43 -0800 (PST) Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h31JicoJ029367 for ; Tue, 1 Apr 2003 11:44:40 -0800 Received: (from robert@localhost) by robur.slu.se (8.9.3p2/8.9.3) id VAA11969; Tue, 1 Apr 2003 21:44:04 +0200 From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16009.60419.764838.337501@robur.slu.se> Date: Tue, 1 Apr 2003 21:44:03 +0200 To: "Feldman, Scott" Cc: Robert Olsson , Jason Lunz , Jeff Garzik , netdev@oss.sgi.com Subject: RE: [Fwd: [E1000] NAPI re-insertion w/ changes] In-Reply-To: References: X-Mailer: VM 6.92 under Emacs 19.34.1 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2130 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 728 Lines: 24 Feldman, Scott writes: > > Also still some concern by having the watchdog kicked in e1000_intr > > wouldn't e1000_clean feel better? > > e1000_intr feels better to me in keeping the clean-up work separate from > managing link status change (hopefully an infrequent event :). Do you > see any problems? Well I was afraid that this would not be run at very heavy loads due to interrupt disabling but I forgot: e1000_watchdog(unsigned long data) { /* Cause software interrupt to ensure rx ring is cleaned */ E1000_WRITE_REG(&adapter->hw, ICS, E1000_ICS_RXDMT0); Which generates irq from watchdog/timer so it should work and all practial experiments indicates this is OK. Cheers. --ro From blueflux@koffein.net Tue Apr 1 12:12:55 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Apr 2003 12:12:57 -0800 (PST) Received: from laptop1.agatha ([195.163.42.244]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h31KCDoJ030617 for ; Tue, 1 Apr 2003 12:12:54 -0800 Received: from localhost (blueflux@localhost) by laptop1.agatha (8.11.6/8.11.6) with ESMTP id h31Jx5j22944; Tue, 1 Apr 2003 21:59:06 +0200 X-Authentication-Warning: laptop1.agatha: blueflux owned process doing -bs Date: Tue, 1 Apr 2003 21:59:05 +0200 (CEST) From: Oskar Andreasson X-X-Sender: blueflux@laptop1.agatha To: "David S. Miller" cc: netdev@oss.sgi.com Subject: Re: [PATCH][RESEND] Update of tcp_syncookies explanation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2131 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: blueflux@koffein.net Precedence: bulk X-list: netdev Content-Length: 1921 Lines: 57 Hi David, Thanks for the reply! It was much appreciated, and I will do what I can to iron any problems out. (Also, I am very sorry for putting you or anyone else out there) My final question is this... could you give any tip on what specifics to look/search for? I've been searching through the archives available at http://oss.sgi.com/projects/netdev/archive/ for every single inclusion of SYN in any of the archives by now, but could not find any specifics on _what_ the syn cookies breaks, or why, except for ECN, SACK and timestamps:/. I have also checked through the source code as well as I could, as well as Mr. Bernsteins algorithms, searched the net at large with 3 search engines... and I am still not clever enough to figure it out. In short, what I am trying to ask for is simply some kind of hints on where to look... I hope you don't mind. Thanks! PS. David, sorry for sending this in private before, no bad intentions meant. DS. On Tue, 1 Apr 2003, David S. Miller wrote: > From: Oskar Andreasson > Date: Tue, 1 Apr 2003 19:33:13 +0200 (CEST) > > If anyone has any objections against this patch, please tell me so, with > an explanation of why! > > You didn't explain how TCP syncookies "seriously violates the TCP > protocol" yet you choose to remove that statement written by Alexey. > > Either retain Alexey's statement (because it's true) or replace it > with proper text. > > I'm not going into the details of how syncookies violates the TCP > protocol here, that has been hashed out many times on netdev and > linux-net years in the past, so I direct people to search up such > discussions instead of starting up yet another flame war here about > the topic. Thanks. > > > -- ---- Oskar Andreasson http://www.frozentux.net http://iptables-tutorial.frozentux.net http://ipsysctl-tutorial.frozentux.net mailto:blueflux@koffein.net From jsd@monmouth.com Tue Apr 1 12:59:42 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Apr 2003 12:59:46 -0800 (PST) Received: from av8n.net (pcp03191463pcs.midltn01.nj.comcast.net [68.37.175.11]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h31KwxoJ031276 for ; Tue, 1 Apr 2003 12:59:42 -0800 Received: (qmail 10967 invoked from network); 1 Apr 2003 20:58:52 -0000 Received: from localhost (HELO monmouth.com) (127.0.0.1) by localhost with SMTP; 1 Apr 2003 20:58:52 -0000 Message-ID: <3E89FD8C.2060607@monmouth.com> Date: Tue, 01 Apr 2003 15:58:52 -0500 From: "John S. Denker" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030323 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Oskar Andreasson CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: defending against syn flood attacks References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2132 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jsd@monmouth.com Precedence: bulk X-list: netdev Content-Length: 1548 Lines: 36 On 04/01/2003 02:59 PM, Oskar Andreasson wrote: >> >> TCP syncookies "seriously violates the TCP protocol" >> ... statement written by Alexey. Those who are interested in defending against syn flood attacks without seriously violating the TCP protocol may be interested in the following: Abstract The protocol of the present invention includes two new first level protocols and several embodiments of a second level protocol. The two new first level protocols of the present invention include the TCP2B protocol and the TCP2E protocol. In the TCP2B protocol, both client and server indicate their support for this protocol using one or more bits in TCP header. According to the TCP2B protocol, the client retransmits its requested options in the ACK message so the server need not store the options after the connection request. In the TCP2E protocol, the server maintains a Friends Table listing addresses of device recently observed to be complying with TCP. If a client's address is on the Friends Table, the connection request is processed according to TCP. Otherwise, the server sends an ACK message to the client to prompt the client to send a reset message. The client's address can then be added to the Friends Table. The patent is held by AT&T. I have no idea how hard it would be to get a license. http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=5,958,053.WKU.+5,958,053.WKU.&OS=PN/5,958,053+OR+PN/5,958,053&RS=PN/5,958,053+OR+PN/5,958,053 From garzik@gtf.org Tue Apr 1 13:17:42 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Apr 2003 13:18:16 -0800 (PST) Received: from havoc.gtf.org (havoc.daloft.com [64.213.145.173]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h31LGvoJ031875 for ; Tue, 1 Apr 2003 13:17:42 -0800 Received: by havoc.gtf.org (Postfix, from userid 500) id D4CA76650; Tue, 1 Apr 2003 21:16:51 +0000 (US/Central) Date: Tue, 1 Apr 2003 16:16:51 -0500 From: Jeff Garzik To: "Feldman, Scott" Cc: Robert Olsson , Jason Lunz , netdev@oss.sgi.com Subject: Re: [Fwd: [E1000] NAPI re-insertion w/ changes] Message-ID: <20030401211651.GA23739@gtf.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2133 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 698 Lines: 22 On Tue, Apr 01, 2003 at 09:47:55AM -0800, Feldman, Scott wrote: > > A better approximation I think but probably not the last... > > Thanks for you help guys! I broke NAPI (don't hate me) and then went on > vacation, so I apologize for not responding sooner. I like what you've > come up with here, so I'll turn the patch around for Jeff to update 2.5 > e1000. > > > + e1000_clean_tx_irq(adapter); > > + e1000_clean_rx_irq(adapter, &work_done, work_to_do); > > Just curious, why give priority to Tx over Rx? TX frees skbs, RX allocates skbs. You lessen the chance of allocation failure or "additional work" being performed by the allocator when you do it in this order. Jeff From scott.feldman@intel.com Tue Apr 1 13:23:13 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Apr 2003 13:23:46 -0800 (PST) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h31LMWoJ032287 for ; Tue, 1 Apr 2003 13:23:13 -0800 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h31LFfD05037 for ; Tue, 1 Apr 2003 21:15:42 GMT Received: from fmsmsxv040-1.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by talaria.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h31LNkc12960 for ; Tue, 1 Apr 2003 21:23:46 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxv040-1.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003040113224111981 ; Tue, 01 Apr 2003 13:22:41 -0800 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Apr 2003 13:22:28 -0800 Message-ID: From: "Feldman, Scott" To: Jeff Garzik Cc: Robert Olsson , Jason Lunz , netdev@oss.sgi.com Subject: RE: [Fwd: [E1000] NAPI re-insertion w/ changes] Date: Tue, 1 Apr 2003 13:22:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2134 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 Content-Length: 323 Lines: 14 > > Just curious, why give priority to Tx over Rx? > > TX frees skbs, RX allocates skbs. > > You lessen the chance of allocation failure or "additional > work" being performed by the allocator when you do it in this order. At the expense of Rx latency. I suppose the best would be: rx_clean tx_clean rx_alloc -scott From toml@us.ibm.com Tue Apr 1 14:04:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Apr 2003 14:04:28 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h31M3aoJ000539 for ; Tue, 1 Apr 2003 14:04:24 -0800 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h31M2umL072412; Tue, 1 Apr 2003 17:02:57 -0500 Received: from tomlt2.austin.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h31M2rdV036296; Tue, 1 Apr 2003 17:02:53 -0500 Subject: [PATCH] IPSec: Use of "sizeof" for header sizes, part II From: Tom Lendacky To: netdev@oss.sgi.com Cc: davem@redhat.com, kuznet@ms2.inr.ac.ru, toml@us.ibm.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 01 Apr 2003 16:04:32 -0600 Message-Id: <1049234673.5116.11.camel@tomlt2.tomloffice.austin.ibm.com> Mime-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2135 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: toml@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 4897 Lines: 132 Below is a patch for your consideration removing the hard coded 8 that represented the ESP spi and sequence number fields. I had to define a pointer to ip(v6)_esp_header in esp(6)_init_state in order to obtain the size of the enc_data member in the most straight forward way. Please review and let me know if any changes are required. Thanks, Tom diff -ur linux-2.5.66-orig/net/ipv4/esp.c linux-2.5.66/net/ipv4/esp.c --- linux-2.5.66-orig/net/ipv4/esp.c 2003-03-31 14:47:18.000000000 -0600 +++ linux-2.5.66/net/ipv4/esp.c 2003-03-31 14:46:39.000000000 -0600 @@ -134,7 +134,8 @@ if (esp->auth.icv_full_len) { esp->auth.icv(esp, skb, (u8*)esph-skb->data, - 8+esp->conf.ivlen+clen, trailer->tail); + (sizeof(struct ip_esp_hdr) - sizeof(esph->enc_data)) + esp->conf.ivlen + clen, + trailer->tail); pskb_put(skb, trailer, alen); } @@ -171,7 +172,7 @@ struct sk_buff *trailer; int blksize = crypto_tfm_alg_blocksize(esp->conf.tfm); int alen = esp->auth.icv_trunc_len; - int elen = skb->len - 8 - esp->conf.ivlen - alen; + int elen = skb->len - (sizeof(struct ip_esp_hdr) - sizeof(esph->enc_data)) - esp->conf.ivlen - alen; int nfrags; if (!pskb_may_pull(skb, sizeof(struct ip_esp_hdr))) @@ -220,7 +221,8 @@ if (!sg) goto out; } - skb_to_sgvec(skb, sg, 8+esp->conf.ivlen, elen); + skb_to_sgvec(skb, sg, + (sizeof(struct ip_esp_hdr) - sizeof(esph->enc_data)) + esp->conf.ivlen, elen); crypto_cipher_decrypt(esp->conf.tfm, sg, sg, elen); if (unlikely(sg != sgbuf)) kfree(sg); @@ -237,8 +239,8 @@ iph->protocol = nexthdr[1]; pskb_trim(skb, skb->len - alen - padlen - 2); memcpy(workbuf, skb->nh.raw, iph->ihl*4); - skb->h.raw = skb_pull(skb, 8 + esp->conf.ivlen); - skb->nh.raw += 8 + esp->conf.ivlen; + skb->h.raw = skb_pull(skb, (sizeof(struct ip_esp_hdr) - sizeof(esph->enc_data)) + esp->conf.ivlen); + skb->nh.raw += (sizeof(struct ip_esp_hdr) - sizeof(esph->enc_data)) + esp->conf.ivlen; memcpy(skb->nh.raw, workbuf, iph->ihl*4); skb->nh.iph->tot_len = htons(skb->len); } @@ -308,6 +310,7 @@ int esp_init_state(struct xfrm_state *x, void *args) { + struct ip_esp_hdr *esph = NULL; struct esp_data *esp = NULL; /* null auth and encryption can have zero length keys */ @@ -365,7 +368,7 @@ get_random_bytes(esp->conf.ivec, esp->conf.ivlen); } crypto_cipher_setkey(esp->conf.tfm, esp->conf.key, esp->conf.key_len); - x->props.header_len = 8 + esp->conf.ivlen; + x->props.header_len = (sizeof(struct ip_esp_hdr) - sizeof(esph->enc_data)) + esp->conf.ivlen; if (x->props.mode) x->props.header_len += sizeof(struct iphdr); x->data = esp; diff -ur linux-2.5.66-orig/net/ipv6/esp6.c linux-2.5.66/net/ipv6/esp6.c --- linux-2.5.66-orig/net/ipv6/esp6.c 2003-03-31 14:47:18.000000000 -0600 +++ linux-2.5.66/net/ipv6/esp6.c 2003-03-31 14:46:39.000000000 -0600 @@ -232,7 +232,8 @@ if (esp->auth.icv_full_len) { esp->auth.icv(esp, skb, (u8*)esph-skb->data, - 8+esp->conf.ivlen+clen, trailer->tail); + (sizeof(struct ipv6_esp_hdr) - sizeof(esph->enc_data)) + esp->conf.ivlen + clen, + trailer->tail); pskb_put(skb, trailer, alen); } @@ -262,7 +263,7 @@ struct sk_buff *trailer; int blksize = crypto_tfm_alg_blocksize(esp->conf.tfm); int alen = esp->auth.icv_trunc_len; - int elen = skb->len - 8 - esp->conf.ivlen - alen; + int elen = skb->len - (sizeof(struct ipv6_esp_hdr) - sizeof(esph->enc_data)) - esp->conf.ivlen - alen; int hdr_len = skb->h.raw - skb->nh.raw; int nfrags; @@ -319,7 +320,7 @@ if (!sg) goto out; } - skb_to_sgvec(skb, sg, 8+esp->conf.ivlen, elen); + skb_to_sgvec(skb, sg, (sizeof(struct ipv6_esp_hdr) - sizeof(esph->enc_data)) + esp->conf.ivlen, elen); crypto_cipher_decrypt(esp->conf.tfm, sg, sg, elen); if (unlikely(sg != sgbuf)) kfree(sg); @@ -338,8 +339,8 @@ ret_nexthdr = ((struct ipv6hdr*)tmp_hdr)->nexthdr = nexthdr[1]; pskb_trim(skb, skb->len - alen - padlen - 2); - skb->h.raw = skb_pull(skb, 8 + esp->conf.ivlen); - skb->nh.raw += 8 + esp->conf.ivlen; + skb->h.raw = skb_pull(skb, (sizeof(struct ipv6_esp_hdr) - sizeof(esph->enc_data)) + esp->conf.ivlen); + skb->nh.raw += (sizeof(struct ipv6_esp_hdr) - sizeof(esph->enc_data)) + esp->conf.ivlen; memcpy(skb->nh.raw, tmp_hdr, hdr_len); } kfree(tmp_hdr); @@ -410,6 +411,7 @@ int esp6_init_state(struct xfrm_state *x, void *args) { + struct ipv6_esp_hdr *esph = NULL; struct esp_data *esp = NULL; if (x->aalg) { @@ -466,7 +468,7 @@ get_random_bytes(esp->conf.ivec, esp->conf.ivlen); } crypto_cipher_setkey(esp->conf.tfm, esp->conf.key, esp->conf.key_len); - x->props.header_len = 8 + esp->conf.ivlen; + x->props.header_len = (sizeof(struct ipv6_esp_hdr) - sizeof(esph->enc_data)) + esp->conf.ivlen; if (x->props.mode) x->props.header_len += sizeof(struct ipv6hdr); x->data = esp; From davem@redhat.com Tue Apr 1 14:12:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Apr 2003 14:12:56 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.8/8.12.5) with SMTP id h31MCCoJ001006 for ; Tue, 1 Apr 2003 14:12:53 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id OAA16242; Tue, 1 Apr 2003 14:07:28 -0800 Date: Tue, 01 Apr 2003 14:07:27 -0800 (PST) Message-Id: <20030401.140727.73666851.davem@redhat.com> To: toml@us.ibm.com Cc: netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: [PATCH] IPSec: Use of "sizeof" for header sizes, part II From: "David S. Miller" In-Reply-To: <1049234673.5116.11.camel@tomlt2.tomloffice.austin.ibm.com> References: <1049234673.5116.11.camel@tomlt2.tomloffice.austin.ibm.com> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2136 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 382 Lines: 12 From: Tom Lendacky Date: 01 Apr 2003 16:04:32 -0600 Please review and let me know if any changes are required. Ok, now that I look at this I realize my suggestions from the other day were wrong. These expressions are huge, it's almost less readable. Let's compact this, by creating a struct named {ip,ipv6}_esp_header_no_enc_data. How about that? From linux-netdev@gmane.org Tue Apr 1 14:40:29 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Apr 2003 14:41:02 -0800 (PST) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h31MeRrX003439 for ; Tue, 1 Apr 2003 14:40:28 -0800 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 190UQL-0003vg-00 for ; Wed, 02 Apr 2003 00:40:09 +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 190UQG-0003vJ-00 for ; Wed, 02 Apr 2003 00:40:04 +0200 From: Jason Lunz Subject: Re: [Fwd: [E1000] NAPI re-insertion w/ changes] Date: Tue, 1 Apr 2003 22:40:03 +0000 (UTC) Organization: PBR Streetgang Message-ID: References: X-Complaints-To: usenet@main.gmane.org User-Agent: slrn/0.9.7.4 (Linux) X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2137 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lunz@reflexsecurity.com Precedence: bulk X-list: netdev Content-Length: 920 Lines: 20 lunz@reflexsecurity.com said: > It works. Reducing PCI accessess gives a measurable improvement. I'll > post plots later today. The graphs are up now. The best driver measured so far is Robert's change to reinstate irq-disable-on-poll + reduce-pci-traffic, with XsumRX turned off. I'm currently measuring to see if it still has an advantage with checksumming turned on. Scott, your bugfix of removing the while() from e1000_clean() puts the original 5.0.43-k1 driver from 2.5.66 back in the running. It no longer suffers from watchdog timeouts, and doesn't degrade under high load. It still scores lowest, though. I've seen that the max-pps-ceiling visible in these graphs is highly sensitive to CPU load, so I'd guess that the sf1 test lost solely because of the overhead of still running the irq handler once in a while. -- Jason Lunz Reflex Security lunz@reflexsecurity.com http://www.reflexsecurity.com/ From scott.feldman@intel.com Tue Apr 1 16:13:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Apr 2003 16:13:51 -0800 (PST) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h320DhrX005019 for ; Tue, 1 Apr 2003 16:13:44 -0800 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h320A5N00551 for ; Wed, 2 Apr 2003 00:10:05 GMT Received: from fmsmsxv040-1.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by talaria.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h320Evc25051 for ; Wed, 2 Apr 2003 00:14:58 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxv040-1.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003040116135024290 ; Tue, 01 Apr 2003 16:13:50 -0800 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Apr 2003 16:13:37 -0800 Message-ID: From: "Feldman, Scott" To: Jason Lunz , Jeff Garzik , Robert Olsson , netdev@oss.sgi.com Subject: RE: [Fwd: [E1000] NAPI re-insertion w/ changes] Date: Tue, 1 Apr 2003 16:13:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2138 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 Content-Length: 1454 Lines: 37 > The graphs are up now. The best driver measured so far is > Robert's change to reinstate irq-disable-on-poll + > reduce-pci-traffic, with XsumRX turned off. I'm currently > measuring to see if it still has an advantage with > checksumming turned on. Very good. Jeff has the patch for -k2 which should be equivalent to -ro2. Robert, please post your -ro3 changes - I can't find them. BTW, the things that changed from 4.4.19-k3 to 5.0.43-k2 that may account for the improvements are: o eliminate the modulus operator for ring index wrapping (anton@samba.org) o single read of ICR (Interrupt Cause Register) in e1000_intr o dynamic ITR (Interrupt Throttle Rate) algorithm for 82545/6 Sum of many second-order improvements add up. We'll take all we can find. > Scott, your bugfix of removing the while() from e1000_clean() > puts the original 5.0.43-k1 driver from 2.5.66 back in the > running. It no longer suffers from watchdog timeouts, and > doesn't degrade under high load. It still scores lowest, > though. I've seen that the max-pps-ceiling visible in these > graphs is highly sensitive to CPU load, so I'd guess that the > sf1 test lost solely because of the overhead of still running > the irq handler once in a while. Ok, that settles that. Thanks for re-running the tests. I'm pretty happy with this NAPI code for e1000. Next step is to get some more generic QA testing with NAPI and then port back to 2.4.x. -scott From yoshfuji@linux-ipv6.org Tue Apr 1 19:25:22 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Apr 2003 19:25:34 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h323PLrX009657 for ; Tue, 1 Apr 2003 19:25:22 -0800 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 h323PIDG015172; Wed, 2 Apr 2003 12:25:18 +0900 Date: Wed, 02 Apr 2003 12:25:18 +0900 (JST) Message-Id: <20030402.122518.62753078.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: toml@us.ibm.com, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPSec: Use of "sizeof" for header sizes, part II From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20030401.140727.73666851.davem@redhat.com> References: <1049234673.5116.11.camel@tomlt2.tomloffice.austin.ibm.com> <20030401.140727.73666851.davem@redhat.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-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2139 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 Content-Length: 982 Lines: 34 In article <20030401.140727.73666851.davem@redhat.com> (at Tue, 01 Apr 2003 14:07:27 -0800 (PST)), "David S. Miller" says: > From: Tom Lendacky > Date: 01 Apr 2003 16:04:32 -0600 > > Please review and let me know if any changes are required. > > Ok, now that I look at this I realize my suggestions from the other > day were wrong. > > These expressions are huge, it's almost less readable. Let's compact > this, by creating a struct named {ip,ipv6}_esp_header_no_enc_data. How about just removing 8 bytes from struct {ip,ipv6}_esp_hdr like this? struct ipv6_auth_hdr { __u8 nexthdr; __u8 hdrlen; __u16 reserved; __u32 spi; __u32 seq_no; __u8 auth_data[0]; } __attribute__ ((aligned (8))); struct ipv6_esp_hdr { __u32 spi; __u32 seq_no; __u8 enc_data[0]; } __attribute__ ((aligned (8))); -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From davem@redhat.com Tue Apr 1 19:39:01 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Apr 2003 19:39:12 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h323d1rX010077 for ; Tue, 1 Apr 2003 19:39:01 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id TAA10335; Tue, 1 Apr 2003 19:34:30 -0800 Date: Tue, 01 Apr 2003 19:34:29 -0800 (PST) Message-Id: <20030401.193429.64279267.davem@redhat.com> To: yoshfuji@linux-ipv6.org Cc: toml@us.ibm.com, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: [PATCH] IPSec: Use of "sizeof" for header sizes, part II From: "David S. Miller" In-Reply-To: <20030402.122518.62753078.yoshfuji@linux-ipv6.org> References: <1049234673.5116.11.camel@tomlt2.tomloffice.austin.ibm.com> <20030401.140727.73666851.davem@redhat.com> <20030402.122518.62753078.yoshfuji@linux-ipv6.org> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2140 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 884 Lines: 21 From: YOSHIFUJI Hideaki / 吉藤英明 Date: Wed, 02 Apr 2003 12:25:18 +0900 (JST) In article <20030401.140727.73666851.davem@redhat.com> (at Tue, 01 Apr 2003 14:07:27 -0800 (PST)), "David S. Miller" says: > From: Tom Lendacky > Date: 01 Apr 2003 16:04:32 -0600 > > Please review and let me know if any changes are required. > > Ok, now that I look at this I realize my suggestions from the other > day were wrong. > > These expressions are huge, it's almost less readable. Let's compact > this, by creating a struct named {ip,ipv6}_esp_header_no_enc_data. How about just removing 8 bytes from struct {ip,ipv6}_esp_hdr like this? Sure, but does anyone need the 8 bytes there? I thought so, which is why I didn't think about your suggestion :-) From becker@scyld.com Tue Apr 1 19:50:56 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Apr 2003 19:51:04 -0800 (PST) Received: from beohost.scyld.com (pcp724216pcs.arlngt01.va.comcast.net [68.49.198.32]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h323oorX010614 for ; Tue, 1 Apr 2003 19:50:55 -0800 Received: from localhost (becker@localhost) by beohost.scyld.com (8.11.6/8.11.6) with ESMTP id h323o7513065; Tue, 1 Apr 2003 22:50:39 -0500 Date: Tue, 1 Apr 2003 22:50:07 -0500 (EST) From: Donald Becker To: Rask Ingemann Lambertsen cc: linux-net@vger.kernel.org, Subject: Re: Must dev->set_multicast_list() complete before returning? In-Reply-To: <3e89cbe235cd78.41777977@not right> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2141 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: becker@scyld.com Precedence: bulk X-list: netdev Content-Length: 694 Lines: 19 On Tue, 1 Apr 2003, Rask Ingemann Lambertsen wrote: > Must dev->set_multicast_list() complete the configuration of a network > device before returning? The promiscuous setting must complete before return, but there are several drivers where the updated multicast filter does not immediately take effect. I have not seen hardware where setting promiscuous mode is a queued command. If you have such hardware, you may have to do some extra software filtering and accept missing some packets during transitions. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From yoshfuji@linux-ipv6.org Tue Apr 1 20:02:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Apr 2003 20:02:32 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h3242NrX011052 for ; Tue, 1 Apr 2003 20:02:23 -0800 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 h3242WDG015405; Wed, 2 Apr 2003 13:02:33 +0900 Date: Wed, 02 Apr 2003 13:02:32 +0900 (JST) Message-Id: <20030402.130232.78951283.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: toml@us.ibm.com, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPSec: Use of "sizeof" for header sizes, part II From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20030401.193429.64279267.davem@redhat.com> References: <20030401.140727.73666851.davem@redhat.com> <20030402.122518.62753078.yoshfuji@linux-ipv6.org> <20030401.193429.64279267.davem@redhat.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-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2142 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 Content-Length: 746 Lines: 21 In article <20030401.193429.64279267.davem@redhat.com> (at Tue, 01 Apr 2003 19:34:29 -0800 (PST)), "David S. Miller" says: > How about just removing 8 bytes from struct {ip,ipv6}_esp_hdr > like this? > > Sure, but does anyone need the 8 bytes there? I thought so, which is > why I didn't think about your suggestion :-) Let's define #define IPV6_ESP_MINDATA 8 and put "(sizeof(struct ip6_esp_hdr) + IPV6_ESP_MINDATA)" in such places. Or, how about this? (offsetof(struct ip6_esp_hdr, enc_data) + datalen) instead of ((sizeof(struct ip6_esp_hdr) - sizeof(esp->enc_data)) + datalen) -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From davem@redhat.com Tue Apr 1 20:06:55 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Apr 2003 20:06:58 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h3246trX011505 for ; Tue, 1 Apr 2003 20:06:55 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id UAA10396; Tue, 1 Apr 2003 20:02:26 -0800 Date: Tue, 01 Apr 2003 20:02:25 -0800 (PST) Message-Id: <20030401.200225.88014087.davem@redhat.com> To: yoshfuji@linux-ipv6.org Cc: toml@us.ibm.com, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: [PATCH] IPSec: Use of "sizeof" for header sizes, part II From: "David S. Miller" In-Reply-To: <20030402.130232.78951283.yoshfuji@linux-ipv6.org> References: <20030402.122518.62753078.yoshfuji@linux-ipv6.org> <20030401.193429.64279267.davem@redhat.com> <20030402.130232.78951283.yoshfuji@linux-ipv6.org> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2143 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 808 Lines: 21 From: YOSHIFUJI Hideaki / 吉藤英明 Date: Wed, 02 Apr 2003 13:02:32 +0900 (JST) In article <20030401.193429.64279267.davem@redhat.com> (at Tue, 01 Apr 2003 19:34:29 -0800 (PST)), "David S. Miller" says: > How about just removing 8 bytes from struct {ip,ipv6}_esp_hdr > like this? > > Sure, but does anyone need the 8 bytes there? I thought so, which is > why I didn't think about your suggestion :-) Let's define #define IPV6_ESP_MINDATA 8 and put "(sizeof(struct ip6_esp_hdr) + IPV6_ESP_MINDATA)" in such places. I just checked, nobody cares about the 8 bytes in enc_data. Therefore, I think you're idea of enc_data[0] is the best. Someone please double check my claims and submit a patch. :-) From linux-netdev@gmane.org Tue Apr 1 20:19:42 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Apr 2003 20:19:48 -0800 (PST) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h324JerX011981 for ; Tue, 1 Apr 2003 20:19:42 -0800 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 190Zie-0006rK-00 for ; Wed, 02 Apr 2003 06:19:24 +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 190Zid-0006rA-00 for ; Wed, 02 Apr 2003 06:19:23 +0200 From: Jason Lunz Subject: Re: [Fwd: [E1000] NAPI re-insertion w/ changes] Date: Wed, 2 Apr 2003 04:19:23 +0000 (UTC) Organization: PBR Streetgang Message-ID: References: X-Complaints-To: usenet@main.gmane.org User-Agent: slrn/0.9.7.4 (Linux) X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2145 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 Content-Length: 1048 Lines: 24 scott.feldman@intel.com said: > Robert, please post your -ro3 changes - I can't find them. sorry, the -roX and -sfX notations are mine; i'm backporting everything to 2.4.20 for testing and most of the patches have to be tweaked one way or another, so I gave them all my own names to help keep them straight. -ro1 and -ro2 come from Robert's posts here, and -ro3 is what you get when you apply ftp://robur.slu.se/pub/Linux/net-development/skb_recycling/e1000_pci_2.pat on top of that. > I'm pretty happy with this NAPI code for e1000. Next step is to get > some more generic QA testing with NAPI and then port back to 2.4.x. For what it's worth, I've subjected various e1000 chipsets to just about every kind of synthetic load all the way up to the maximum theoretical full-duplex gigE framerate for hours without a hiccup. I'm using backports from 2.5 with the TSO stuff stripped out. Judging from my apache logs and the emails I get, quite a few others have been using those patches on 2.4 too, but I've received no real complaints. Jason From scott.feldman@intel.com Tue Apr 1 20:19:24 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Apr 2003 20:19:30 -0800 (PST) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h324JJrX011946 for ; Tue, 1 Apr 2003 20:19:24 -0800 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h324FeB02479 for ; Wed, 2 Apr 2003 04:15:40 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by talaria.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h324KZi21128 for ; Wed, 2 Apr 2003 04:20:35 GMT Received: from FMSMSX017.fm.intel.com ([132.233.42.196]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003040120165316542 ; Tue, 01 Apr 2003 20:16:53 -0800 Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Apr 2003 20:19:18 -0800 Message-ID: From: "Feldman, Scott" To: "Patrick R. McManus" , netdev@oss.sgi.com Subject: RE: Intel 1000 MT slow to restart Date: Tue, 1 Apr 2003 20:19:12 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2144 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 Content-Length: 1015 Lines: 23 > I'm running intel's e1000 driver (versions 4.4.12 and tried > 4.6.11) for a 1000/MT (dual) nic on a 2.4.19 kernel. > > for normal operations, everything is fine.. however if I do a > "ifconfig eth0 down; ifconfig eth0 up" 20 or 30 seconds > passes where I can't do any traffic. the ifconfig up comes > back quickly, and ifconfig reports the driver as up (and > netlink thinks its up if I try and add another one).. I just > can't move any traffic. no rx's and my tx's only move > counters in the driver - they don't actually make it to the wire. > > if I do "ifconfig eth0 down; sleep 30; ifconfig eth0 up" all > is well immediately after the up.. The driver doesn't seem to > be doing anything different in either case - its as if the > NIC itself is enforcing some kind of quiet period. > > I'm really writing to see if I'm crazy and hoping someone > else can corroborate this is what they've seen too. Do you have spanning tree turned on on your switch? This could cause such delays. -scott From yoshfuji@linux-ipv6.org Tue Apr 1 20:20:25 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 01 Apr 2003 20:20:30 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h324KOrX012246 for ; Tue, 1 Apr 2003 20:20:25 -0800 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 h324KYDG015547; Wed, 2 Apr 2003 13:20:34 +0900 Date: Wed, 02 Apr 2003 13:20:34 +0900 (JST) Message-Id: <20030402.132034.126030996.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: toml@us.ibm.com, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPSec: Use of "sizeof" for header sizes, part II From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20030401.200225.88014087.davem@redhat.com> References: <20030401.193429.64279267.davem@redhat.com> <20030402.130232.78951283.yoshfuji@linux-ipv6.org> <20030401.200225.88014087.davem@redhat.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-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2146 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 Content-Length: 537 Lines: 14 In article <20030401.200225.88014087.davem@redhat.com> (at Tue, 01 Apr 2003 20:02:25 -0800 (PST)), "David S. Miller" says: > I just checked, nobody cares about the 8 bytes in enc_data. > > Therefore, I think you're idea of enc_data[0] is the best. > > Someone please double check my claims and submit a patch. :-) Okay, I'll check it (and make a patch) in this afternoon (in a few hours). -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From shmulik.hen@intel.com Wed Apr 2 04:54:07 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Apr 2003 04:54:12 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h32Cs4rX031205 for ; Wed, 2 Apr 2003 04:54:06 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h32CnrA17644 for ; Wed, 2 Apr 2003 12:49:53 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h32Cuek10294 for ; Wed, 2 Apr 2003 12:56:40 GMT Received: from hasmsx17.iil.intel.com ([143.185.63.203]) by hasmsxvs01.iil.intel.com (NAVGW 2.5.2.11) with SMTP id M2003040215591201636 ; Wed, 02 Apr 2003 15:59:12 +0300 Received: by hasmsx17.iil.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Apr 2003 15:53:57 +0300 Message-ID: From: "Hen, Shmulik" To: "Feldman, Scott" , "Patrick R. McManus" , netdev@oss.sgi.com Subject: RE: Intel 1000 MT slow to restart Date: Wed, 2 Apr 2003 15:53:52 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2147 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 Content-Length: 1488 Lines: 40 > -----Original Message----- > From: Feldman, Scott > Sent: Wednesday, April 02, 2003 7:19 AM > To: Patrick R. McManus; netdev@oss.sgi.com > Subject: RE: Intel 1000 MT slow to restart > > > > I'm running intel's e1000 driver (versions 4.4.12 and tried > > 4.6.11) for a 1000/MT (dual) nic on a 2.4.19 kernel. > > > > for normal operations, everything is fine.. however if I do a > > "ifconfig eth0 down; ifconfig eth0 up" 20 or 30 seconds > > passes where I can't do any traffic. the ifconfig up comes > > back quickly, and ifconfig reports the driver as up (and > > netlink thinks its up if I try and add another one).. I just > > can't move any traffic. no rx's and my tx's only move > > counters in the driver - they don't actually make it to the wire. > > > > if I do "ifconfig eth0 down; sleep 30; ifconfig eth0 up" all > > is well immediately after the up.. The driver doesn't seem to > > be doing anything different in either case - its as if the > > NIC itself is enforcing some kind of quiet period. > > > > I'm really writing to see if I'm crazy and hoping someone > > else can corroborate this is what they've seen too. > > Do you have spanning tree turned on on your switch? This could cause > such delays. > > -scott > We've also seen this behavior with certain switches (e.g. Extreme Networks Summit 7i) even with STP turned off. The switch simply delays traffic for ~30sec after link was restored. I believe this delay is configurable. Shmulik. From rask@sygehus.dk Wed Apr 2 05:01:52 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Apr 2003 05:01:56 -0800 (PST) Received: from cicero0.cybercity.dk (cicero0.cybercity.dk [212.242.40.52]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h32D1orX031703 for ; Wed, 2 Apr 2003 05:01:52 -0800 Received: from user4.cybercity.dk (fxp0.user4.ip.cybercity.dk [212.242.41.50]) by cicero0.cybercity.dk (Postfix) with ESMTP id 897E4102B26; Wed, 2 Apr 2003 15:01:49 +0200 (CEST) Received: from webmail.cybercity.dk (webmail.cybercity.dk [212.242.40.37]) by user4.cybercity.dk (Postfix) with SMTP id 0AAB155C4; Wed, 2 Apr 2003 15:01:49 +0200 (CEST) Reply-To: rask@sygehus.dk From: rask@sygehus.dk (Rask Ingemann Lambertsen) To: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Is a driver allowed to modify dev->flags? Date: Wed, 2 Apr 2003 15:01:49 +0200 Message-Id: <3e8adf3d2fe3c6.82986008@not right> References: <3e89c32348ce76.94538914@not right> X-Authenticated-IP: [152.95.52.86] X-Sender: ccc94453@vip.cybercity.dk X-Mailer: Cybercity Webmail 1.06 (http://webmail.cybercity.dk/) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2148 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rask@sygehus.dk Precedence: bulk X-list: netdev Content-Length: 368 Lines: 14 I wrote: > Is a network device driver allowed to modify dev->flags? For example: > > if (dev->flags & IFF_ALLMULTI) > dev->flags |= IFF_PROMISC; Maybe the right question is: Is it necessary for the driver to set the IFF_PROMISC flag if the device enters promiscuous mode because it doesn't support all-multicast mode? Regards, Rask Ingemann Lambertsen From rask@sygehus.dk Wed Apr 2 05:51:02 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Apr 2003 05:51:09 -0800 (PST) Received: from cicero0.cybercity.dk (cicero0.cybercity.dk [212.242.40.52]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h32DoorX004328 for ; Wed, 2 Apr 2003 05:50:51 -0800 Received: from user3.cybercity.dk (fxp0.user3.ip.cybercity.dk [212.242.41.36]) by cicero0.cybercity.dk (Postfix) with ESMTP id 2B9DC102A20; Wed, 2 Apr 2003 15:09:15 +0200 (CEST) Received: from webmail.cybercity.dk (webmail.cybercity.dk [212.242.40.37]) by user3.cybercity.dk (Postfix) with SMTP id B718D332; Wed, 2 Apr 2003 15:09:14 +0200 (CEST) Reply-To: rask@sygehus.dk From: rask@sygehus.dk (Rask Ingemann Lambertsen) To: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Must dev->set_multicast_list() complete before returning? Date: Wed, 2 Apr 2003 15:09:14 +0200 Message-Id: <3e8ae0facf3cc3.47481623@not right> References: X-Authenticated-IP: [152.95.52.86] X-Sender: ccc94453@vip.cybercity.dk X-Mailer: Cybercity Webmail 1.06 (http://webmail.cybercity.dk/) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2149 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rask@sygehus.dk Precedence: bulk X-list: netdev Content-Length: 493 Lines: 16 Donald Becker wrote: > The promiscuous setting must complete before return, but there are > several drivers where the updated multicast filter does not immediately > take effect. > > I have not seen hardware where setting promiscuous mode is a queued > command. Intel i82586, i82596 and, as far as I can tell from other drivers, several other Intel i825xx Ethernet chips. IIRC, the function must not sleep. That means busy-wait for it to complete. :-( Regards, Rask Ingemann Lambertsen From toml@us.ibm.com Wed Apr 2 07:01:53 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Apr 2003 07:02:29 -0800 (PST) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h32F1krX008727 for ; Wed, 2 Apr 2003 07:01:53 -0800 Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.56.224.151]) by e3.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h32F0E9k135280; Wed, 2 Apr 2003 10:00:14 -0500 Received: from d01ml072.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by northrelay03.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h32F057J062192; Wed, 2 Apr 2003 10:00:11 -0500 Subject: Re: [PATCH] IPSec: Use of "sizeof" for header sizes, part II To: YOSHIFUJI Hideaki Cc: davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, "Hideaki YOSHIFUJI" X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: "Tom Lendacky" Date: Wed, 2 Apr 2003 09:00:03 -0600 X-MIMETrack: Serialize by Router on D01ML072/01/M/IBM(Release 5.0.11 +SPRs MIAS5EXFG4, MIAS5AUFPV and DHAG4Y6R7W, MATTEST |November 8th, 2002) at 04/02/2003 10:00:12 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2150 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: toml@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 271 Lines: 11 I just noticed the use of the AH_HLEN_NOICV #define which is hardcoded to be 12. The patch should probably take the change to the esp header and apply it to the auth header also (as shown in an earlier post) and then eliminate the hardcoding of the 12. Thanks, Tom From david-b@pacbell.net Wed Apr 2 08:06:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Apr 2003 08:07:04 -0800 (PST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h32G6QrX013095 for ; Wed, 2 Apr 2003 08:06:26 -0800 Received: from pacbell.net ([67.118.247.200]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) with ESMTP id <0HCQ00KF14QOTV@mta6.snfc21.pbi.net> for netdev@oss.sgi.com; Wed, 02 Apr 2003 08:06:26 -0800 (PST) Date: Wed, 02 Apr 2003 08:18:11 -0800 From: David Brownell Subject: Re: Must dev->set_multicast_list() complete before returning? To: Donald Becker Cc: Rask Ingemann Lambertsen , linux-net@vger.kernel.org, netdev@oss.sgi.com Message-id: <3E8B0D43.2000003@pacbell.net> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us, en, fr User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513 References: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2151 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: david-b@pacbell.net Precedence: bulk X-list: netdev Content-Length: 482 Lines: 20 Donald Becker wrote: > > I have not seen hardware where setting promiscuous mode is a queued > command. If you have such hardware, you may have to do some extra > software filtering and accept missing some packets during transitions. Every USB network adapter will need to queue such commands, unless they don't support such operations at all. So you have probably seen such hardware, without realizing it! I just looked ... none of them do any extra filtering. - Dave From gandalf@wlug.westbo.se Wed Apr 2 09:23:21 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Apr 2003 09:23:29 -0800 (PST) Received: from tux.rsn.bth.se (postfix@tux.rsn.bth.se [194.47.143.135]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h32HNIrX018415 for ; Wed, 2 Apr 2003 09:23:20 -0800 Received: by tux.rsn.bth.se (Postfix, from userid 501) id C410E36FCD; Wed, 2 Apr 2003 19:23:14 +0200 (CEST) Subject: Re: loopback behaviour under high load ... From: Martin Josefsson To: Davide Libenzi Cc: Linux Kernel Mailing List , netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1049304194.25168.56.camel@tux.rsn.bth.se> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 02 Apr 2003 19:23:14 +0200 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2152 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gandalf@wlug.westbo.se Precedence: bulk X-list: netdev Content-Length: 11251 Lines: 116 On Wed, 2003-04-02 at 18:23, Davide Libenzi wrote: > On Tue, 1 Apr 2003, Davide Libenzi wrote: > > > And netstat shows Recv-Q=0 for the server socket, and Send-Q=N for the > > client socket. This has been tested on 2.5.66 vanilla. > > An update on this. Kernel 2.4.20+epoll does not have this problem. I see something similar with 2.5.64-bk10 (seen with earlier 2.5 kernels as well). I use distcc on my machine which is running 2.5.64-bk10 and using two remote servers running 2.4.20 to do the compiling. Sometimes I see a ~120s stall in the middle of a connection with Recv-Q=0 on the server (2.4.20) and Send-Q=N on the client (2.5.64-bk10) (it's the client that's sending data to the server) x.x.x.x = client y.y.y.y = server As you can see there's a long delay between 16:02:09 and 16:04:24 There's some packetloss here (probably a congested interface in the router on the way). The dump was made on the client. I've included a lot of the dump to give some context. It appears the 111073:112497(1424) packet at 16:02:09.597800 going to the server was dropped and the server continues acking the previous packet. It takes a very long time until the client resends the missing packet and it appears it's been dropped once again. Then no packets are sent in either direction until the missing packet is retransmitted after a 120s timeout and the connection continues. (I hope there isn't any missing packets in this dump, libpcap without mmap dropped a lot but with mmap support it said it didn't drop a single packet) [snip] 16:02:09.445650 x.x.x.x.57798 > y.y.y.y.3632: . 95409:96833(1424) ack 1 win 730 (DF) 16:02:09.445665 x.x.x.x.57798 > y.y.y.y.3632: P 96833:98257(1424) ack 1 win 730 (DF) 16:02:09.445683 x.x.x.x.57798 > y.y.y.y.3632: . 98257:99681(1424) ack 1 win 730 (DF) 16:02:09.445695 x.x.x.x.57798 > y.y.y.y.3632: . 99681:101105(1424) ack 1 win 730 (DF) 16:02:09.451822 y.y.y.y.3632 > x.x.x.x.57798: . ack 84017 win 64080 (DF) 16:02:09.452573 y.y.y.y.3632 > x.x.x.x.57798: . ack 86865 win 64080 (DF) 16:02:09.452740 y.y.y.y.3632 > x.x.x.x.57798: . ack 89713 win 64080 (DF) 16:02:09.452989 y.y.y.y.3632 > x.x.x.x.57798: . ack 92561 win 64080 (DF) 16:02:09.453352 y.y.y.y.3632 > x.x.x.x.57798: . ack 95409 win 64080 (DF) 16:02:09.454195 y.y.y.y.3632 > x.x.x.x.57798: . ack 98257 win 64080 (DF) 16:02:09.454400 y.y.y.y.3632 > x.x.x.x.57798: . ack 101105 win 64080 (DF) 16:02:09.597688 x.x.x.x.57798 > y.y.y.y.3632: P 101105:102529(1424) ack 1 win 730 (DF) 16:02:09.597702 x.x.x.x.57798 > y.y.y.y.3632: . 102529:103953(1424) ack 1 win 730 (DF) 16:02:09.597721 x.x.x.x.57798 > y.y.y.y.3632: . 103953:105377(1424) ack 1 win 730 (DF) 16:02:09.597734 x.x.x.x.57798 > y.y.y.y.3632: P 105377:106801(1424) ack 1 win 730 (DF) 16:02:09.597755 x.x.x.x.57798 > y.y.y.y.3632: . 106801:108225(1424) ack 1 win 730 (DF) 16:02:09.597768 x.x.x.x.57798 > y.y.y.y.3632: . 108225:109649(1424) ack 1 win 730 (DF) 16:02:09.597787 x.x.x.x.57798 > y.y.y.y.3632: . 109649:111073(1424) ack 1 win 730 (DF) 16:02:09.597800 x.x.x.x.57798 > y.y.y.y.3632: . 111073:112497(1424) ack 1 win 730 (DF) 16:02:09.597818 x.x.x.x.57798 > y.y.y.y.3632: P 112497:113921(1424) ack 1 win 730 (DF) 16:02:09.597832 x.x.x.x.57798 > y.y.y.y.3632: . 113921:115345(1424) ack 1 win 730 (DF) 16:02:09.597849 x.x.x.x.57798 > y.y.y.y.3632: . 115345:116769(1424) ack 1 win 730 (DF) 16:02:09.597862 x.x.x.x.57798 > y.y.y.y.3632: P 116769:118193(1424) ack 1 win 730 (DF) 16:02:09.597903 x.x.x.x.57798 > y.y.y.y.3632: . 118193:119617(1424) ack 1 win 730 (DF) 16:02:09.597915 x.x.x.x.57798 > y.y.y.y.3632: . 119617:121041(1424) ack 1 win 730 (DF) 16:02:09.610011 y.y.y.y.3632 > x.x.x.x.57798: . ack 103953 win 64080 (DF) 16:02:09.610486 y.y.y.y.3632 > x.x.x.x.57798: . ack 106801 win 64080 (DF) 16:02:09.610899 y.y.y.y.3632 > x.x.x.x.57798: . ack 109649 win 64080 (DF) 16:02:09.611921 y.y.y.y.3632 > x.x.x.x.57798: . ack 111073 win 64080 (DF) 16:02:09.611944 y.y.y.y.3632 > x.x.x.x.57798: . ack 111073 win 64080 (DF) 16:02:09.611963 y.y.y.y.3632 > x.x.x.x.57798: . ack 111073 win 64080 (DF) 16:02:09.611996 y.y.y.y.3632 > x.x.x.x.57798: . ack 111073 win 64080 (DF) 16:02:09.703860 x.x.x.x.57798 > y.y.y.y.3632: P 121041:122465(1424) ack 1 win 730 (DF) 16:02:09.703873 x.x.x.x.57798 > y.y.y.y.3632: . 122465:123889(1424) ack 1 win 730 (DF) 16:02:09.703892 x.x.x.x.57798 > y.y.y.y.3632: . 123889:125313(1424) ack 1 win 730 (DF) 16:02:09.703908 x.x.x.x.57798 > y.y.y.y.3632: P 125313:126737(1424) ack 1 win 730 (DF) 16:02:09.703926 x.x.x.x.57798 > y.y.y.y.3632: . 126737:128161(1424) ack 1 win 730 (DF) 16:02:09.703939 x.x.x.x.57798 > y.y.y.y.3632: . 128161:129585(1424) ack 1 win 730 (DF) 16:02:09.705559 x.x.x.x.57798 > y.y.y.y.3632: P 129585:131009(1424) ack 1 win 730 (DF) 16:02:09.705565 x.x.x.x.57798 > y.y.y.y.3632: . 131009:132433(1424) ack 1 win 730 (DF) 16:02:09.705570 x.x.x.x.57798 > y.y.y.y.3632: . 132433:133857(1424) ack 1 win 730 (DF) 16:02:09.705574 x.x.x.x.57798 > y.y.y.y.3632: P 133857:135281(1424) ack 1 win 730 (DF) 16:02:09.705578 x.x.x.x.57798 > y.y.y.y.3632: . 135281:136705(1424) ack 1 win 730 (DF) 16:02:09.714200 y.y.y.y.3632 > x.x.x.x.57798: . ack 111073 win 64080 (DF) 16:02:09.714499 y.y.y.y.3632 > x.x.x.x.57798: . ack 111073 win 64080 (DF) 16:02:09.714698 y.y.y.y.3632 > x.x.x.x.57798: . ack 111073 win 64080 (DF) 16:02:09.714772 y.y.y.y.3632 > x.x.x.x.57798: . ack 111073 win 64080 (DF) 16:02:09.715358 y.y.y.y.3632 > x.x.x.x.57798: . ack 111073 win 64080 (DF) 16:02:09.715361 y.y.y.y.3632 > x.x.x.x.57798: . ack 111073 win 64080 (DF) 16:02:09.715550 y.y.y.y.3632 > x.x.x.x.57798: . ack 111073 win 64080 (DF) 16:02:09.715552 y.y.y.y.3632 > x.x.x.x.57798: . ack 111073 win 64080 (DF) 16:02:09.715672 y.y.y.y.3632 > x.x.x.x.57798: . ack 111073 win 64080 (DF) 16:02:09.715675 y.y.y.y.3632 > x.x.x.x.57798: . ack 111073 win 64080 (DF) 16:02:09.715677 y.y.y.y.3632 > x.x.x.x.57798: . ack 111073 win 64080 (DF) 16:02:09.808712 x.x.x.x.57798 > y.y.y.y.3632: . 136705:138129(1424) ack 1 win 730 (DF) 16:02:09.808735 x.x.x.x.57798 > y.y.y.y.3632: P 138129:139548(1419) ack 1 win 730 (DF) 16:02:09.808784 x.x.x.x.57798 > y.y.y.y.3632: . 111073:112497(1424) ack 1 win 730 (DF) 16:02:09.808813 x.x.x.x.57798 > y.y.y.y.3632: P 112497:113921(1424) ack 1 win 730 (DF) 16:02:09.808838 x.x.x.x.57798 > y.y.y.y.3632: . 119617:121041(1424) ack 1 win 730 (DF) 16:02:09.822496 y.y.y.y.3632 > x.x.x.x.57798: . ack 111073 win 64080 (DF) 16:02:09.822498 y.y.y.y.3632 > x.x.x.x.57798: . ack 111073 win 64080 (DF) 16:04:24.936079 x.x.x.x.57798 > y.y.y.y.3632: . 111073:112497(1424) ack 1 win 730 (DF) 16:04:24.938582 y.y.y.y.3632 > x.x.x.x.57798: . ack 112497 win 62656 (DF) 16:04:24.939909 x.x.x.x.57798 > y.y.y.y.3632: P 112497:113921(1424) ack 1 win 730 (DF) 16:04:24.939937 x.x.x.x.57798 > y.y.y.y.3632: . 119617:121041(1424) ack 1 win 730 (DF) 16:04:24.942568 y.y.y.y.3632 > x.x.x.x.57798: . ack 119617 win 55536 (DF) 16:04:24.942573 y.y.y.y.3632 > x.x.x.x.57798: . ack 139548 win 46992 (DF) 16:04:25.038755 y.y.y.y.3632 > x.x.x.x.57798: P 1:1166(1165) ack 139548 win 64080 (DF) 16:04:25.038765 y.y.y.y.3632 > x.x.x.x.57798: F 1166:1166(0) ack 139548 win 64080 (DF) 16:04:25.038893 x.x.x.x.57798 > y.y.y.y.3632: . ack 1166 win 1019 (DF) 16:04:25.039286 x.x.x.x.57798 > y.y.y.y.3632: F 139548:139548(0) ack 1167 win 1019 (DF) 16:04:25.041470 y.y.y.y.3632 > x.x.x.x.57798: . ack 139549 win 64080 (DF) -- /Martin From becker@scyld.com Wed Apr 2 11:40:03 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Apr 2003 11:40:12 -0800 (PST) Received: from beohost.scyld.com (dsl093-058-082.blt1.dsl.speakeasy.net [66.93.58.82]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h32Je1rX020043 for ; Wed, 2 Apr 2003 11:40:03 -0800 Received: from localhost (becker@localhost) by beohost.scyld.com (8.11.6/8.11.6) with ESMTP id h32JePl14814; Wed, 2 Apr 2003 14:40:25 -0500 Date: Wed, 2 Apr 2003 14:40:24 -0500 (EST) From: Donald Becker To: David Brownell cc: Rask Ingemann Lambertsen , , Subject: Re: Must dev->set_multicast_list() complete before returning? In-Reply-To: <3E8B0D43.2000003@pacbell.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2153 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: becker@scyld.com Precedence: bulk X-list: netdev Content-Length: 1684 Lines: 40 On Wed, 2 Apr 2003, David Brownell wrote: > Donald Becker wrote: > > > > I have not seen hardware where setting promiscuous mode is a queued > > command. If you have such hardware, you may have to do some extra > > software filtering and accept missing some packets during transitions. > > Every USB network adapter will need to queue such commands, > unless they don't support such operations at all. So you > have probably seen such hardware, without realizing it! Errrm, a previous message pointed out to me that there were several other Intel chips that _I had written drivers for_ that queue commands. And yes, I had also forgotten about bridged NICs such as USB (which I've also written drivers for). > I just looked ... none of them do any extra filtering. I've not added extra filtering to any driver USB or otherwise. It may be that there is a problem here that is rarely encountered and never identified as a problem. A filter change from promiscuous to normal mode is at worst a narrow window. The atp.c driver is special because it put the hardware into promiscuous mode for allmulti, and thus any potential problem became a continuous issue. Alan, do you remember what piece of code had a problem with unicast packets to other hosts that would normally be filtered out by the hardware? It may be that issue is gone with 2.4 and later kernels. (Multicast is not an issue because most chips use an imperfect hash filter and thus the kernel has always needed additional filtering.) -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From rddunlap@osdl.org Wed Apr 2 12:27:49 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Apr 2003 12:27:54 -0800 (PST) Received: from mail.osdl.org (air-2.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h32KRmrX023273 for ; Wed, 2 Apr 2003 12:27:49 -0800 Received: from dragon.pdx.osdl.net (dragon.pdx.osdl.net [172.20.1.27]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id h32KRkW28048; Wed, 2 Apr 2003 12:27:46 -0800 Date: Wed, 2 Apr 2003 12:27:55 +0000 From: "Randy.Dunlap" To: linux-net@vger.kernel.org Cc: netdev@oss.sgi.com Subject: snmp stats as %ld or %lu Message-Id: <20030402122755.5dc3f022.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2154 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Content-Length: 182 Lines: 11 Hi, ipv4/proc.c prints SNMP stats using %lu, but ipv6/proc.c prints them using %ld. Is this difference intentional, planned, or an oversight, or something else? Thanks, -- ~Randy From davidel@xmailserver.org Wed Apr 2 14:49:35 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Apr 2003 14:49:38 -0800 (PST) Received: from x35.xmailserver.org (x35.xmailserver.org [208.129.208.51]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h32MnYDH025532 for ; Wed, 2 Apr 2003 14:49:34 -0800 X-AuthUser: davidel@xmailserver.org Received: from blue1.dev.mcafeelabs.com (161.69.79.199:54284) by xmailserver.org with [XMail 1.14 (Linux/Ix86) ESMTP Server] id for from ; Wed, 02 Apr 2003 15:13:30 -0800 Date: Wed, 2 Apr 2003 14:47:04 -0800 (PST) From: Davide Libenzi X-X-Sender: davide@blue1.dev.mcafeelabs.com To: Martin Josefsson cc: Linux Kernel Mailing List , "" Subject: Re: loopback behaviour under high load ... In-Reply-To: <1049304194.25168.56.camel@tux.rsn.bth.se> Message-ID: References: <1049304194.25168.56.camel@tux.rsn.bth.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2155 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davidel@xmailserver.org Precedence: bulk X-list: netdev Content-Length: 1529 Lines: 46 On Wed, 2 Apr 2003, Martin Josefsson wrote: > On Wed, 2003-04-02 at 18:23, Davide Libenzi wrote: > > On Tue, 1 Apr 2003, Davide Libenzi wrote: > > > > > And netstat shows Recv-Q=0 for the server socket, and Send-Q=N for the > > > client socket. This has been tested on 2.5.66 vanilla. > > > > An update on this. Kernel 2.4.20+epoll does not have this problem. > > I see something similar with 2.5.64-bk10 (seen with earlier 2.5 kernels > as well). > > I use distcc on my machine which is running 2.5.64-bk10 and using two > remote servers running 2.4.20 to do the compiling. > > Sometimes I see a ~120s stall in the middle of a connection with > Recv-Q=0 on the server (2.4.20) and Send-Q=N on the client (2.5.64-bk10) > (it's the client that's sending data to the server) > > x.x.x.x = client > y.y.y.y = server > > As you can see there's a long delay between 16:02:09 and 16:04:24 > > There's some packetloss here (probably a congested interface in the > router on the way). The dump was made on the client. Hmm, we don't see any dropped packet at interface ( loopback ) level here: $ cat /proc/net/softnet_stat 002a0c14 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 $ ifconfig lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:1349417 errors:0 dropped:0 overruns:0 frame:0 TX packets:1349417 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 - Davide From fubar@us.ibm.com Wed Apr 2 17:02:48 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Apr 2003 17:02:57 -0800 (PST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h3312fDH026781 for ; Wed, 2 Apr 2003 17:02:47 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h3312XdA138990; Wed, 2 Apr 2003 20:02:33 -0500 Received: from death.ibm.com (lig32-226-144-94.us.lig-dial.ibm.com [32.226.144.94]) by northrelay04.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h3312TeR156884; Wed, 2 Apr 2003 20:02:30 -0500 Received: from us.ibm.com (fubar@localhost) by death.ibm.com (8.12.5/8.12.5/Submit) with ESMTP id h33113tc015107; Wed, 2 Apr 2003 17:01:04 -0800 Message-Id: <200304030101.h33113tc015107@death.ibm.com> X-Authentication-Warning: death.ibm.com: fubar owned process doing -bs To: "Hen, Shmulik" , "Marom, Noam" , "Feldman, Scott" cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: RE: [Bonding-devel] [patch] (2/8) Add 802.3ad support to bonding Date: Wed, 02 Apr 2003 17:01:03 -0800 From: Jay Vosburgh X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2156 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1848 Lines: 41 I've been trying various things with the 802.3ad patch, and am seeing a behavior that seems erroneous, but it could be that I'm missing something (in the standard, for example) that explains it. I have two systems, connected via an 802.3ad capable switch. System A has 4 10/100 ethernets connected to the switch, which are all ifenslaved into a single 802.3ad mode bond (with miimon=100). System B has a single 10/100 connected to the switch. As a traffic generator, I telnet from System A to System B's chargen service, and let it run. I see activity on two of the bond's four links (which is expected, one for incoming, one for outgoing). If I unplug either of the active cables from the switch, bonding notices immediately and transfers the connection to a different interface. If, however, I use "ifenslave -d bond0 ethX" (where ethX is one of the active interfaces, by which I mean one with traffic flowing over it), it takes a considerable amount of real time for bonding to recover and transfer the connection to a new interface. It appears that the deleted interface must be either the transmitting or receiving interface (I'm not sure which), as sometimes it recovers immediately. Removing an idle interface from the bond does not appear to cause any stalls. Also, curiously, if I "ifenslave bond0 ethX" where ethX is an already enslaved interface, I get an EBUSY error printed by ifenslave, but the data transmission stalls for a period of time. Presumably this is due to some of the prepatory work done by ifenslave, but I have not yet investigated precisely what it is. Ifenslave also seems to leave the interface in a down state, which may be the cause of the stall (if the interface is removed from the bond because it's down). Any thoughts? -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com From yoshfuji@linux-ipv6.org Wed Apr 2 20:51:03 2003 Received: with ECARTIS (v1.0.0; list netdev); Wed, 02 Apr 2003 20:51:14 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h334p1DH032168 for ; Wed, 2 Apr 2003 20:51:03 -0800 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 h334p4DG024058; Thu, 3 Apr 2003 13:51:07 +0900 Date: Thu, 03 Apr 2003 13:51:04 +0900 (JST) Message-Id: <20030403.135104.748509693.yoshfuji@linux-ipv6.org> To: toml@us.ibm.com, davem@redhat.com, kuznet@ms2.inr.ac.ru Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPSec: Use of "sizeof" for header sizes, part II From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: 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 XEmacs 21.4.6 (Common Lisp) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2157 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 Content-Length: 9793 Lines: 269 In article (at Wed, 2 Apr 2003 09:00:03 -0600), "Tom Lendacky" says: > > I just noticed the use of the AH_HLEN_NOICV #define which is hardcoded to > be 12. The patch should probably take the change to the esp header and > apply it to the auth header also (as shown in an earlier post) and then > eliminate the hardcoding of the 12. Agreed. Here's the patch against linux-2.5.66 + ChangeSet 1.1004. Thanks. Index: include/linux/ip.h =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux25/include/linux/ip.h,v retrieving revision 1.1.1.4 retrieving revision 1.1.1.4.14.1 diff -u -r1.1.1.4 -r1.1.1.4.14.1 --- include/linux/ip.h 22 Mar 2003 01:52:35 -0000 1.1.1.4 +++ include/linux/ip.h 2 Apr 2003 10:17:41 -0000 1.1.1.4.14.1 @@ -188,13 +188,13 @@ __u16 reserved; __u32 spi; __u32 seq_no; /* Sequence number */ - __u8 auth_data[4]; /* Variable len but >=4. Mind the 64 bit alignment! */ + __u8 auth_data[0]; /* Variable len but >=4. Mind the 64 bit alignment! */ }; struct ip_esp_hdr { __u32 spi; __u32 seq_no; /* Sequence number */ - __u8 enc_data[8]; /* Variable len but >=8. Mind the 64 bit alignment! */ + __u8 enc_data[0]; /* Variable len but >=8. Mind the 64 bit alignment! */ }; #endif /* _LINUX_IP_H */ Index: include/linux/ipv6.h =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux25/include/linux/ipv6.h,v retrieving revision 1.1.1.4 retrieving revision 1.1.1.4.14.1 diff -u -r1.1.1.4 -r1.1.1.4.14.1 --- include/linux/ipv6.h 22 Mar 2003 01:52:37 -0000 1.1.1.4 +++ include/linux/ipv6.h 2 Apr 2003 10:17:41 -0000 1.1.1.4.14.1 @@ -80,13 +80,13 @@ __u16 reserved; __u32 spi; __u32 seq_no; /* Sequence number */ - __u8 auth_data[4]; /* Length variable but >=4. Mind the 64 bit alignment! */ + __u8 auth_data[0]; /* Length variable but >=4. Mind the 64 bit alignment! */ }; struct ipv6_esp_hdr { __u32 spi; __u32 seq_no; /* Sequence number */ - __u8 enc_data[8]; /* Length variable but >=8. Mind the 64 bit alignment! */ + __u8 enc_data[0]; /* Length variable but >=8. Mind the 64 bit alignment! */ }; /* Index: net/ipv4/ah.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux25/net/ipv4/ah.c,v retrieving revision 1.1.1.10 retrieving revision 1.1.1.10.2.1 diff -u -r1.1.1.10 -r1.1.1.10.2.1 --- net/ipv4/ah.c 2 Apr 2003 07:25:57 -0000 1.1.1.10 +++ net/ipv4/ah.c 3 Apr 2003 01:40:12 -0000 1.1.1.10.2.1 @@ -9,8 +9,6 @@ #include -#define AH_HLEN_NOICV 12 - /* Clear mutable options and find final destination to substitute * into IP header for icv calculation. Options are already checked * for validity, so paranoia is not required. */ @@ -116,8 +114,8 @@ ah->nexthdr = iph->protocol; } ahp = x->data; - ah->hdrlen = (XFRM_ALIGN8(ahp->icv_trunc_len + - AH_HLEN_NOICV) >> 2) - 2; + ah->hdrlen = (XFRM_ALIGN8(sizeof(struct ip_auth_hdr) + + ahp->icv_trunc_len) >> 2) - 2; ah->reserved = 0; ah->spi = x->id.spi; @@ -169,8 +167,8 @@ ahp = x->data; ah_hlen = (ah->hdrlen + 2) << 2; - if (ah_hlen != XFRM_ALIGN8(ahp->icv_full_len + AH_HLEN_NOICV) && - ah_hlen != XFRM_ALIGN8(ahp->icv_trunc_len + AH_HLEN_NOICV)) + if (ah_hlen != XFRM_ALIGN8(sizeof(struct ip_auth_hdr) + ahp->icv_full_len) && + ah_hlen != XFRM_ALIGN8(sizeof(struct ip_auth_hdr) + ahp->icv_trunc_len)) goto out; if (!pskb_may_pull(skb, ah_hlen)) @@ -286,7 +284,7 @@ if (!ahp->work_icv) goto error; - x->props.header_len = XFRM_ALIGN8(ahp->icv_trunc_len + AH_HLEN_NOICV); + x->props.header_len = XFRM_ALIGN8(sizeof(struct ip_auth_hdr) + ahp->icv_trunc_len); if (x->props.mode) x->props.header_len += sizeof(struct iphdr); x->data = ahp; Index: net/ipv4/esp.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux25/net/ipv4/esp.c,v retrieving revision 1.1.1.9 retrieving revision 1.1.1.9.2.1 diff -u -r1.1.1.9 -r1.1.1.9.2.1 --- net/ipv4/esp.c 2 Apr 2003 07:25:57 -0000 1.1.1.9 +++ net/ipv4/esp.c 2 Apr 2003 10:17:41 -0000 1.1.1.9.2.1 @@ -134,7 +134,7 @@ if (esp->auth.icv_full_len) { esp->auth.icv(esp, skb, (u8*)esph-skb->data, - 8+esp->conf.ivlen+clen, trailer->tail); + sizeof(struct ip_esp_hdr) + esp->conf.ivlen+clen, trailer->tail); pskb_put(skb, trailer, alen); } @@ -171,7 +171,7 @@ struct sk_buff *trailer; int blksize = crypto_tfm_alg_blocksize(esp->conf.tfm); int alen = esp->auth.icv_trunc_len; - int elen = skb->len - 8 - esp->conf.ivlen - alen; + int elen = skb->len - sizeof(struct ip_esp_hdr) - esp->conf.ivlen - alen; int nfrags; if (!pskb_may_pull(skb, sizeof(struct ip_esp_hdr))) @@ -220,7 +220,7 @@ if (!sg) goto out; } - skb_to_sgvec(skb, sg, 8+esp->conf.ivlen, elen); + skb_to_sgvec(skb, sg, sizeof(struct ip_esp_hdr) + esp->conf.ivlen, elen); crypto_cipher_decrypt(esp->conf.tfm, sg, sg, elen); if (unlikely(sg != sgbuf)) kfree(sg); @@ -237,8 +237,8 @@ iph->protocol = nexthdr[1]; pskb_trim(skb, skb->len - alen - padlen - 2); memcpy(workbuf, skb->nh.raw, iph->ihl*4); - skb->h.raw = skb_pull(skb, 8 + esp->conf.ivlen); - skb->nh.raw += 8 + esp->conf.ivlen; + skb->h.raw = skb_pull(skb, sizeof(struct ip_esp_hdr) + esp->conf.ivlen); + skb->nh.raw += sizeof(struct ip_esp_hdr) + esp->conf.ivlen; memcpy(skb->nh.raw, workbuf, iph->ihl*4); skb->nh.iph->tot_len = htons(skb->len); } @@ -365,7 +365,7 @@ get_random_bytes(esp->conf.ivec, esp->conf.ivlen); } crypto_cipher_setkey(esp->conf.tfm, esp->conf.key, esp->conf.key_len); - x->props.header_len = 8 + esp->conf.ivlen; + x->props.header_len = sizeof(struct ip_esp_hdr) + esp->conf.ivlen; if (x->props.mode) x->props.header_len += sizeof(struct iphdr); x->data = esp; Index: net/ipv6/ah6.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux25/net/ipv6/ah6.c,v retrieving revision 1.1.1.5 retrieving revision 1.1.1.5.2.1 diff -u -r1.1.1.5 -r1.1.1.5.2.1 --- net/ipv6/ah6.c 2 Apr 2003 07:25:59 -0000 1.1.1.5 +++ net/ipv6/ah6.c 3 Apr 2003 01:40:12 -0000 1.1.1.5.2.1 @@ -36,8 +36,6 @@ #include #include -#define AH_HLEN_NOICV 12 - /* XXX no ipv6 ah specific */ #define NIP6(addr) \ ntohs((addr).s6_addr16[0]),\ @@ -110,8 +108,8 @@ skb->nh.ipv6h->hop_limit = 0; ahp = x->data; - ah->hdrlen = (XFRM_ALIGN8(ahp->icv_trunc_len + - AH_HLEN_NOICV) >> 2) - 2; + ah->hdrlen = (XFRM_ALIGN8(sizeof(struct ipv6_auth_hdr) + + ahp->icv_trunc_len) >> 2) - 2; ah->reserved = 0; ah->spi = x->id.spi; @@ -165,8 +163,8 @@ ahp = x->data; ah_hlen = (ah->hdrlen + 2) << 2; - if (ah_hlen != XFRM_ALIGN8(ahp->icv_full_len + AH_HLEN_NOICV) && - ah_hlen != XFRM_ALIGN8(ahp->icv_trunc_len + AH_HLEN_NOICV)) + if (ah_hlen != XFRM_ALIGN8(sizeof(struct ipv6_auth_hdr) + ahp->icv_full_len) && + ah_hlen != XFRM_ALIGN8(sizeof(struct ipv6_auth_hdr) + ahp->icv_trunc_len)) goto out; if (!pskb_may_pull(skb, ah_hlen)) @@ -285,7 +283,7 @@ if (!ahp->work_icv) goto error; - x->props.header_len = XFRM_ALIGN8(ahp->icv_trunc_len + AH_HLEN_NOICV); + x->props.header_len = XFRM_ALIGN8(sizeof(struct ipv6_auth_hdr) + ahp->icv_trunc_len); if (x->props.mode) x->props.header_len += sizeof(struct ipv6hdr); x->data = ahp; Index: net/ipv6/esp6.c =================================================================== RCS file: /cvsroot/usagi/usagi-backport/linux25/net/ipv6/esp6.c,v retrieving revision 1.1.1.5 retrieving revision 1.1.1.5.2.1 diff -u -r1.1.1.5 -r1.1.1.5.2.1 --- net/ipv6/esp6.c 2 Apr 2003 07:25:59 -0000 1.1.1.5 +++ net/ipv6/esp6.c 2 Apr 2003 10:17:41 -0000 1.1.1.5.2.1 @@ -232,7 +232,7 @@ if (esp->auth.icv_full_len) { esp->auth.icv(esp, skb, (u8*)esph-skb->data, - 8+esp->conf.ivlen+clen, trailer->tail); + sizeof(struct ipv6_esp_hdr) + esp->conf.ivlen+clen, trailer->tail); pskb_put(skb, trailer, alen); } @@ -262,7 +262,7 @@ struct sk_buff *trailer; int blksize = crypto_tfm_alg_blocksize(esp->conf.tfm); int alen = esp->auth.icv_trunc_len; - int elen = skb->len - 8 - esp->conf.ivlen - alen; + int elen = skb->len - sizeof(struct ipv6_esp_hdr) - esp->conf.ivlen - alen; int hdr_len = skb->h.raw - skb->nh.raw; int nfrags; @@ -319,7 +319,7 @@ if (!sg) goto out; } - skb_to_sgvec(skb, sg, 8+esp->conf.ivlen, elen); + skb_to_sgvec(skb, sg, sizeof(struct ipv6_esp_hdr) + esp->conf.ivlen, elen); crypto_cipher_decrypt(esp->conf.tfm, sg, sg, elen); if (unlikely(sg != sgbuf)) kfree(sg); @@ -338,8 +338,8 @@ ret_nexthdr = ((struct ipv6hdr*)tmp_hdr)->nexthdr = nexthdr[1]; pskb_trim(skb, skb->len - alen - padlen - 2); - skb->h.raw = skb_pull(skb, 8 + esp->conf.ivlen); - skb->nh.raw += 8 + esp->conf.ivlen; + skb->h.raw = skb_pull(skb, sizeof(struct ipv6_esp_hdr) + esp->conf.ivlen); + skb->nh.raw += sizeof(struct ipv6_esp_hdr) + esp->conf.ivlen; memcpy(skb->nh.raw, tmp_hdr, hdr_len); } kfree(tmp_hdr); @@ -466,7 +466,7 @@ get_random_bytes(esp->conf.ivec, esp->conf.ivlen); } crypto_cipher_setkey(esp->conf.tfm, esp->conf.key, esp->conf.key_len); - x->props.header_len = 8 + esp->conf.ivlen; + x->props.header_len = sizeof(struct ipv6_esp_hdr) + esp->conf.ivlen; if (x->props.mode) x->props.header_len += sizeof(struct ipv6hdr); x->data = esp; -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From davem@redhat.com Thu Apr 3 04:25:30 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Apr 2003 04:25:39 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h33CPTDH009865 for ; Thu, 3 Apr 2003 04:25:30 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id EAA31426; Thu, 3 Apr 2003 04:20:09 -0800 Date: Thu, 03 Apr 2003 04:20:09 -0800 (PST) Message-Id: <20030403.042009.28704472.davem@redhat.com> To: yoshfuji@linux-ipv6.org Cc: toml@us.ibm.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: [PATCH] IPSec: Use of "sizeof" for header sizes, part II From: "David S. Miller" In-Reply-To: <20030403.135104.748509693.yoshfuji@linux-ipv6.org> References: <20030403.135104.748509693.yoshfuji@linux-ipv6.org> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2158 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 676 Lines: 15 From: YOSHIFUJI Hideaki / 吉藤英明 Date: Thu, 03 Apr 2003 13:51:04 +0900 (JST) In article (at Wed, 2 Apr 2003 09:00:03 -0600), "Tom Lendacky" says: > > I just noticed the use of the AH_HLEN_NOICV #define which is hardcoded to > be 12. The patch should probably take the change to the esp header and > apply it to the auth header also (as shown in an earlier post) and then > eliminate the hardcoding of the 12. Agreed. Here's the patch against linux-2.5.66 + ChangeSet 1.1004. Thanks. Patch applied, thank you. From davem@redhat.com Thu Apr 3 04:53:05 2003 Received: with ECARTIS (v1.0.0; list netdev); Thu, 03 Apr 2003 04:53:13 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.5) with SMTP id h33Cr5DH010322 for ; Thu, 3 Apr 2003 04:53:05 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id EAA31549; Thu, 3 Apr 2003 04:48:22 -0800 Date: Thu, 03 Apr 2003 04:48:22 -0800 (PST) Message-Id: <20030403.044822.00469453.davem@redhat.com> To: rddunlap@osdl.org Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: snmp stats as %ld or %lu From: "David S. Miller" In-Reply-To: <20030402122755.5dc3f022.rddunlap@osdl.org> References: <20030402122755.5dc3f022.rddunlap@osdl.org> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-archive-position: 2159 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 327 Lines: 10 From: "Randy.Dunlap" Date: Wed, 2 Apr 2003 12:27:55 +0000 ipv4/proc.c prints SNMP stats using %lu, but i