From shin-5@jp-c.ne.jp Wed Dec 1 02:02:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Dec 2004 02:02:06 -0800 (PST) Received: from MIN14 ([221.212.226.3]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iB1A1wn1011500 for ; Wed, 1 Dec 2004 02:01:59 -0800 Date: Wed, 1 Dec 2004 02:01:58 -0800 Message-Id: <200412011001.iB1A1wn1011500@oss.sgi.com> From: "=?iso-2022-jp?B?c2pkazE0QHlhaG9vLmNvLmpw?=" To: "netdev@oss.sgi.com" X-mailer: Super Mailer 9 [en][outlook] Subject: =?iso-2022-jp?B?GyRCISE0KCQkJEckOSQrISkbKEI=?= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-archive-position: 12362 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alkjd@yahoo.co.jp Precedence: bulk X-list: netdev いいね〜今週も最高です！ http://iidote.info/kinjyo ****メルマガ解除/問い合わせ**** 広東省　藩　浩 yotsuba_kouyou@yahoo.co.jp ******************************* From hadi@cyberus.ca Wed Dec 1 05:23:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Dec 2004 05:23:19 -0800 (PST) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB1DNB1C021461 for ; Wed, 1 Dec 2004 05:23:12 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1CZURT-0003Du-Es for netdev@oss.sgi.com; Wed, 01 Dec 2004 08:22:47 -0500 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CZURP-0008Vw-8l; Wed, 01 Dec 2004 08:22:43 -0500 Subject: Re: [E1000-devel] Transmission limit From: jamal Reply-To: hadi@cyberus.ca To: Lennert Buytenhek Cc: Robert Olsson , P@draigBrady.com, mellia@prezzemolo.polito.it, e1000-devel@lists.sourceforge.net, Jorge Manuel Finochietto , Giulio Galante , netdev@oss.sgi.com In-Reply-To: <20041201001107.GE4203@xi.wantstofly.org> References: <1101467291.24742.70.camel@mellia.lipar.polito.it> <41A73826.3000109@draigBrady.com> <16807.20052.569125.686158@robur.slu.se> <1101484740.24742.213.camel@mellia.lipar.polito.it> <41A76085.7000105@draigBrady.com> <1101499285.1079.45.camel@jzny.localdomain> <16811.8052.678955.795327@robur.slu.se> <1101821501.1043.43.camel@jzny.localdomain> <20041130134600.GA31515@xi.wantstofly.org> <1101824754.1044.126.camel@jzny.localdomain> <20041201001107.GE4203@xi.wantstofly.org> Content-Type: text/plain Organization: jamalopolous Message-Id: <1101902900.1041.9.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 01 Dec 2004 07:08:20 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 12363 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Tue, 2004-11-30 at 19:11, Lennert Buytenhek wrote: > On Tue, Nov 30, 2004 at 09:25:54AM -0500, jamal wrote: > > > > > > Also from what I understand new HW and MSI can help in the case where > > > > > pass objects between CPU. Did I dream or did someone tell me that S2IO > > > > > could have several TX ring that could via MSI be routed to proper cpu? > > > > > > > > I am wondering if the per CPU tx/rx irqs are valuable at all. They sound > > > > like more hell to maintain. > > > > > > On the TX path you'd have qdiscs to deal with as well, no? > > > > I think management of it would be non-trivial in SMP. Youd have to start > > playing stupid loadbalancing tricks which would reduce the value of > > existence of tx irqs to begin with. > > You mean the management of qdiscs would be non-trivial? I mean it is useful in only the most ideal cases and if you want to actually do something useful in most cases with it you will have to muck around. Take the case of forwarding (maybe with a little or almost no localhost generated traffic) - then you end allocating in CPUA, processing and queueing on egress. Tx softirq, which is what stashes the packet on tx DMA eventually, is not guaranteed to run on the same CPU. Now add a little latency between ingress and egress .. The ideal case is where you end up processing to completion from ingress to egress (which is known to happen in Linux when theres no congestion). > Probably the idea of these kinds of tricks is to skip the qdisc step > altogether. > Which is preached by the BSD folks - bogus in my opinion. If you want to do something as bland/boring as that you can probably afford a $500 DLINK router which can do it at wire rate with (with cost you being locked in whatever features they have). cheers, jamal From hadi@cyberus.ca Wed Dec 1 05:40:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Dec 2004 05:40:46 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB1Debev022056 for ; Wed, 1 Dec 2004 05:40:41 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1CZUiL-0006Ct-BZ for netdev@oss.sgi.com; Wed, 01 Dec 2004 08:40:13 -0500 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1CZUiH-000245-JX; Wed, 01 Dec 2004 08:40:09 -0500 Subject: Re: [E1000-devel] Transmission limit From: jamal Reply-To: hadi@cyberus.ca To: mellia@prezzemolo.polito.it Cc: Lennert Buytenhek , Harald Welte , P@draigBrady.com, e1000-devel@lists.sourceforge.net, Jorge Manuel Finochietto , Giulio Galante , netdev@oss.sgi.com In-Reply-To: <1101804146.11111.23.camel@mellia.lipar.polito.it> References: <1101467291.24742.70.camel@mellia.lipar.polito.it> <41A73826.3000109@draigBrady.com> <1101483081.24742.174.camel@mellia.lipar.polito.it> <20041127092503.GA12592@sunbeam.de.gnumonks.org> <1101718412.14930.46.camel@verza.polito.it> <20041129145028.GC18788@xi.wantstofly.org> <1101804146.11111.23.camel@mellia.lipar.polito.it> Content-Type: text/plain Organization: jamalopolous Message-Id: <1101903944.1042.29.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 01 Dec 2004 07:25:44 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 12364 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Tue, 2004-11-30 at 03:42, Marco Mellia wrote: > On Mon, 2004-11-29 at 15:50, Lennert Buytenhek wrote: > > On Mon, Nov 29, 2004 at 09:53:33AM +0100, Marco Mellia wrote: > > > > > Th's our intuition too. > > > Notice that we get the same results with 3com (broadcom based) gigabit > > > cards. > > > We are thinking of sending packet in "bursts" instead of single > > > transfers. The only problem is to let the NIC know that there are more > > > than a packet in a burst... > > > > Jamal implemented exactly this for e1000 already, he might be persuaded > > into posting his patch here. Jamal? :) > > I guess that saying that we are _very_ interested in this might help. > :-) > We can offer as "beta-testers" as well... Sorry missed this (I wasnt CCed so it went to a low priority queue which i read on a best effort basis). Let me clean up the patches a little bit this weekend. The patch is at least 4 months old; latest reincarnation was due to issue1 on my SUCON presentation. Would a patch against latest 2.6.x bitkeeper (whatever it is this weekend) be fine? If you are in a rush and dont mind a little ugliness then i will pass them as is. BTW, Scott posted a interesting patch yesterday, you may wanna give that a shot as well. cheers, jamal From buytenh@wantstofly.org Wed Dec 1 07:24:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Dec 2004 07:25:08 -0800 (PST) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB1FOtOe011798 for ; Wed, 1 Dec 2004 07:24:56 -0800 Received: by xi.wantstofly.org (Postfix, from userid 500) id 09F592B0ED; Wed, 1 Dec 2004 16:24:33 +0100 (MET) Date: Wed, 1 Dec 2004 16:24:33 +0100 From: Lennert Buytenhek To: jamal Cc: Robert Olsson , P@draigBrady.com, mellia@prezzemolo.polito.it, e1000-devel@lists.sourceforge.net, Jorge Manuel Finochietto , Giulio Galante , netdev@oss.sgi.com Subject: Re: [E1000-devel] Transmission limit Message-ID: <20041201152433.GA12558@xi.wantstofly.org> References: <16807.20052.569125.686158@robur.slu.se> <1101484740.24742.213.camel@mellia.lipar.polito.it> <41A76085.7000105@draigBrady.com> <1101499285.1079.45.camel@jzny.localdomain> <16811.8052.678955.795327@robur.slu.se> <1101821501.1043.43.camel@jzny.localdomain> <20041130134600.GA31515@xi.wantstofly.org> <1101824754.1044.126.camel@jzny.localdomain> <20041201001107.GE4203@xi.wantstofly.org> <1101902900.1041.9.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1101902900.1041.9.camel@jzny.localdomain> User-Agent: Mutt/1.4.1i X-archive-position: 12365 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev On Wed, Dec 01, 2004 at 07:08:20AM -0500, jamal wrote: [ per-CPU TX/RX rings ] > > You mean the management of qdiscs would be non-trivial? > > I mean it is useful in only the most ideal cases and if you want to > actually do something useful in most cases with it you will have to > muck around. > Take the case of forwarding (maybe with a little or almost no localhost > generated traffic) - then you end allocating in CPUA, processing and > queueing on egress. Tx softirq, which is what stashes the packet on tx > DMA eventually, is not guaranteed to run on the same CPU. Now add a > little latency between ingress and egress .. > The ideal case is where you end up processing to completion from ingress > to egress (which is known to happen in Linux when theres no congestion). We disagreed on this topic at SUCON and I'm afraid we'll be disagreeing on it forever :) IMHO, on 10GbE any kind of qdisc is a waste of cycles. I don't think it's very likely that you'll be using that single 10GbE NIC for forwarding packets, doing that with a PC at this point in the history of PCs is just silly. If you do use it for forwarding, how likely is it that you'll be able to process an incoming burst of packets fast enough to require queueing on the egress interface? You have to be able to send a burst of packets bigger than the NIC's TX FIFO at >10GbE in the first place for queueing to be effective/useful at all. (Leaving the question of whether or not there'll be some room in the TX FIFO at TX time unanswered, what you're doing with per-CPU TX rings is basically just simulating the "N individual NICs each bound to its own CPU" case with a single NIC.) > > Probably the idea of these kinds of tricks is to skip the qdisc step > > altogether. > > Which is preached by the BSD folks - bogus in my opinion. If you want to > do something as bland/boring as that you can probably afford a $500 > DLINK router which can do it at wire rate with (with cost you being > locked in whatever features they have). That's an unfair comparison. Just because I don't need CBQ doesn't mean my $500 DLINK router does everything I'd want it to -- advanced firewalling is one thing that comes to mind. Last time I looked I couldn't load my own kernel modules on my DLINK router either. --L From Robert.Olsson@data.slu.se Wed Dec 1 07:34:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Dec 2004 07:34:58 -0800 (PST) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB1FYmVv012294 for ; Wed, 1 Dec 2004 07:34:53 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id iB1FYCKO029728; Wed, 1 Dec 2004 16:34:12 +0100 Received: by robur.slu.se (Postfix, from userid 1000) id 5C1C6EC001; Wed, 1 Dec 2004 16:34:12 +0100 (CET) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16813.58484.343629.570703@robur.slu.se> Date: Wed, 1 Dec 2004 16:34:12 +0100 To: sfeldma@pobox.com Cc: Lennert Buytenhek , jamal , Robert Olsson , P@draigBrady.com, mellia@prezzemolo.polito.it, e1000-devel@lists.sourceforge.net, Jorge Manuel Finochietto , Giulio Galante , netdev@oss.sgi.com Subject: Re: [E1000-devel] Transmission limit In-Reply-To: <1101863399.4663.54.camel@sfeldma-mobl.dsl-verizon.net> References: <1101467291.24742.70.camel@mellia.lipar.polito.it> <41A73826.3000109@draigBrady.com> <16807.20052.569125.686158@robur.slu.se> <1101484740.24742.213.camel@mellia.lipar.polito.it> <41A76085.7000105@draigBrady.com> <1101499285.1079.45.camel@jzny.localdomain> <16811.8052.678955.795327@robur.slu.se> <1101821501.1043.43.camel@jzny.localdomain> <20041130134600.GA31515@xi.wantstofly.org> <1101824754.1044.126.camel@jzny.localdomain> <20041201001107.GE4203@xi.wantstofly.org> <1101863399.4663.54.camel@sfeldma-mobl.dsl-verizon.net> X-Mailer: VM 7.18 under Emacs 21.3.1 X-archive-position: 12366 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 Scott Feldman writes: > Hey, turns out, I know some e1000 tricks that might help get the kpps > numbers up. > > My problem is I only have a P4 desktop system with a 82544 nic running > at PCI 32/33Mhz, so I can't play with the big boys. But, attached is a > rework of the Tx path to eliminate 1) Tx interrupts, and 2) Tx > descriptor write-backs. For me, I see a nice jump in kpps, but I'd like > others to try with their setups. We should be able to get to wire speed > with 60-byte packets. > > System: Intel 865 (HT 2.6Ghz) > Nic: 82544 PCI 32-bit/33Mhz > Driver: linux-2.6.9 e1000 (5.3.19-k2-NAPI), no Interrupt Delays > 4096 descs > pkt_size = 60: 541618pps 277Mb/sec errors: 914 Hello! Nice but I no improvements w. 82546GB @ 133 MHz on 1.6 GHz Opteron it seems. SMP kernel linux-2.6.9-rc2 Vanilla. 801077pps 410Mb/sec (410151424bps) errors: 95596 Patch TXD=4096 608690pps 311Mb/sec (311649280bps) errors: 0 Patch TXD=2048 624103pps 319Mb/sec (319540736bps) errors: 0 Patch TXD=1024 551289pps 282Mb/sec (282259968bps) errors: 4506 Error count is a bit confusing... --ro From sfeldma@pobox.com Wed Dec 1 08:47:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Dec 2004 08:47:45 -0800 (PST) Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB1GlafG018005 for ; Wed, 1 Dec 2004 08:47:41 -0800 Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id EAD952F9553; Wed, 1 Dec 2004 11:47:14 -0500 (EST) Received: from [172.20.3.21] (66.239.228.194.ptr.us.xo.net [66.239.228.194]) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id D00302F84CC; Wed, 1 Dec 2004 11:47:04 -0500 (EST) Subject: Re: [E1000-devel] Transmission limit From: Scott Feldman Reply-To: sfeldma@pobox.com To: Robert Olsson Cc: Lennert Buytenhek , jamal , P@draigBrady.com, mellia@prezzemolo.polito.it, e1000-devel@lists.sourceforge.net, Jorge Manuel Finochietto , Giulio Galante , netdev@oss.sgi.com In-Reply-To: <16813.58484.343629.570703@robur.slu.se> References: <1101467291.24742.70.camel@mellia.lipar.polito.it> <41A73826.3000109@draigBrady.com> <16807.20052.569125.686158@robur.slu.se> <1101484740.24742.213.camel@mellia.lipar.polito.it> <41A76085.7000105@draigBrady.com> <1101499285.1079.45.camel@jzny.localdomain> <16811.8052.678955.795327@robur.slu.se> <1101821501.1043.43.camel@jzny.localdomain> <20041130134600.GA31515@xi.wantstofly.org> <1101824754.1044.126.camel@jzny.localdomain> <20041201001107.GE4203@xi.wantstofly.org> <1101863399.4663.54.camel@sfeldma-mobl.dsl-verizon.net> <16813.58484.343629.570703@robur.slu.se> Content-Type: text/plain Message-Id: <1101919791.5198.15.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 01 Dec 2004 08:49:51 -0800 Content-Transfer-Encoding: 7bit X-archive-position: 12367 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sfeldma@pobox.com Precedence: bulk X-list: netdev On Wed, 2004-12-01 at 07:34, Robert Olsson wrote: > Nice but I no improvements w. 82546GB @ 133 MHz on 1.6 GHz Opteron it seems. > SMP kernel linux-2.6.9-rc2 > > Vanilla. > 801077pps 410Mb/sec (410151424bps) errors: 95596 > > Patch TXD=4096 > 608690pps 311Mb/sec (311649280bps) errors: 0 Thank you Robert for trying it out. Well those results are counter-intuitive! We remove Tx interrupts and Tx descriptor DMA write-backs and get no re-tries, and performance drops? The only bus activities left are the DMA of buffers to device and the register writes to increment tail. I'm stumped. I'll need to get my hands on a faster system. Maybe there is a bus analyzer under the tree. :-) -scott From Robert.Olsson@data.slu.se Wed Dec 1 08:48:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Dec 2004 08:48:19 -0800 (PST) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB1Gm7iB018063 for ; Wed, 1 Dec 2004 08:48:14 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id iB1GlOKO024025; Wed, 1 Dec 2004 17:47:24 +0100 Received: by robur.slu.se (Postfix, from userid 1000) id 34CC8EC001; Wed, 1 Dec 2004 17:47:24 +0100 (CET) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16813.62876.180869.404122@robur.slu.se> Date: Wed, 1 Dec 2004 17:47:24 +0100 To: "David S. Miller" Cc: Robert Olsson , hadi@cyberus.ca, P@draigBrady.com, mellia@prezzemolo.polito.it, e1000-devel@lists.sourceforge.net, jorge.finochietto@polito.it, galante@polito.it, netdev@oss.sgi.com Subject: Re: [E1000-devel] Transmission limit In-Reply-To: <20041129121604.47eb6593.davem@davemloft.net> References: <1101467291.24742.70.camel@mellia.lipar.polito.it> <41A73826.3000109@draigBrady.com> <16807.20052.569125.686158@robur.slu.se> <1101484740.24742.213.camel@mellia.lipar.polito.it> <41A76085.7000105@draigBrady.com> <1101499285.1079.45.camel@jzny.localdomain> <16811.8052.678955.795327@robur.slu.se> <20041129121604.47eb6593.davem@davemloft.net> X-Mailer: VM 7.18 under Emacs 21.3.1 X-archive-position: 12368 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 David S. Miller writes: > > Did I dream or did someone tell me that S2IO > > could have several TX ring that could via MSI be routed to proper cpu? > > One of Sun's gigabit chips can do this too, except it isn't > via MSI, the driver has to read the descriptor to figure out > which cpu gets the software interrupt to process the packet. > > SGI had hardware which allowed you to do this kind of stuff too. > > Obviously the MSI version works much better. > > It is important, the cpu selection process. First of all, it must > be calculated such that flows always go through the same cpu. > Otherwise TCP sockets bounce between the cpus for a streaming > transfer. > > And even this doesn't avoid all such problems, TCP LISTEN state > sockets will still thrash between the cpus with such a "pick > a cpu based upon" flow scheme. > > Anyways, just some thoughts. Thanks for the the info. Well we'll be forced to get into those problems when the HW is capable. I'll guess it will be w. the 10 GIGE cards. --ro From wensong@linux-vs.org Wed Dec 1 08:49:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Dec 2004 08:50:02 -0800 (PST) Received: from lb1.ctrip.com ([218.244.111.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB1Gnqeo018487 for ; Wed, 1 Dec 2004 08:49:53 -0800 Received: from penguin.linux-vs.org ([61.149.145.226]) by lb1.ctrip.com (8.12.10/8.12.10) with ESMTP id iB1GmjMh028406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Dec 2004 00:48:49 +0800 Received: from penguin.linux-vs.org (localhost.localdomain [127.0.0.1]) by penguin.linux-vs.org (8.12.8/8.12.8) with ESMTP id iB1GmZ9A001083; Thu, 2 Dec 2004 00:48:36 +0800 Received: from localhost (wensong@localhost) by penguin.linux-vs.org (8.12.8/8.12.8/Submit) with ESMTP id iB1GmRZa001079; Thu, 2 Dec 2004 00:48:31 +0800 X-Authentication-Warning: penguin.linux-vs.org: wensong owned process doing -bs Date: Thu, 2 Dec 2004 00:48:26 +0800 (CST) From: Wensong Zhang To: "David S. Miller" , netdev@oss.sgi.com Subject: [PATCH] [IPVS] add a sysctl variable to expire quiescent template Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="-1463811584-572891765-1097000265=:2451" Content-ID: X-archive-position: 12369 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wensong@linux-vs.org 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. ---1463811584-572891765-1097000265=:2451 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Content-ID: Hi Dave, Here is the patch from Horms to add a sysctl variable to expire quiescent templat. Please check and apply them to kernel 2.4 and 2.6 respectively. Thanks, Wensong ---1463811584-572891765-1097000265=:2451 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="linux-2.4-ipvs-quiescent_template.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="linux-2.4-ipvs-quiescent_template.patch" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBkaWZmIC1OcnUgc3R5 bGUgcGF0Y2guDQojDQojIENoYW5nZVNldA0KIyAgIDIwMDQvMTIvMDIgMDA6 MDI6NDgrMDg6MDAgd2Vuc29uZ0BsaW51eC12cy5vcmcgDQojICAgW0lQVlNd IGFkZCBhIHN5c2N0bCB2YXJpYWJsZSB0byBleHBpcmUgcXVpZXNjZW50IHRl bXBsYXRlDQojICAgDQojICAgVGhlIHBhdGNoIGlzIGZyb20gSG9ybXMgPGhv cm1zQHZlcmdlbmV0Lm5ldD4NCiMgDQojIG5ldC9pcHY0L2lwdnMvaXBfdnNf Y3RsLmMNCiMgICAyMDA0LzEyLzAyIDAwOjAyOjM4KzA4OjAwIHdlbnNvbmdA bGludXgtdnMub3JnICs0IC0wDQojICAgc2V0IHN5c2N0bF9pcF92c19leHBp cmVfcXVpZXNjZW50X3RlbXBsYXRlDQojIA0KIyBuZXQvaXB2NC9pcHZzL2lw X3ZzX2Nvbm4uYw0KIyAgIDIwMDQvMTIvMDIgMDA6MDI6MzcrMDg6MDAgd2Vu c29uZ0BsaW51eC12cy5vcmcgKzMgLTENCiMgICBkb24ndCB1c2UgcXVpZXNj ZW50IHRlbXBsYXRlIGlmIHRoZSBleHBpcmVfcXVpZXNjZW50X3RlbXBsYXRl IGlzIGVuYWJsZWQNCiMgDQojIGluY2x1ZGUvbmV0L2lwX3ZzLmgNCiMgICAy MDA0LzEyLzAyIDAwOjAyOjM3KzA4OjAwIHdlbnNvbmdAbGludXgtdnMub3Jn ICsyIC0wDQojICAgYWRkIHRoZSBzeXNjdGxfaXBfdnNfZXhwaXJlX3F1aWVz Y2VudF90ZW1wbGF0ZQ0KIyANCmRpZmYgLU5ydSBhL2luY2x1ZGUvbmV0L2lw X3ZzLmggYi9pbmNsdWRlL25ldC9pcF92cy5oDQotLS0gYS9pbmNsdWRlL25l dC9pcF92cy5oCTIwMDQtMTItMDIgMDA6MTY6MzYgKzA4OjAwDQorKysgYi9p bmNsdWRlL25ldC9pcF92cy5oCTIwMDQtMTItMDIgMDA6MTY6MzYgKzA4OjAw DQpAQCAtMzE3LDYgKzMxNyw3IEBADQogCU5FVF9JUFY0X1ZTX0VYUElSRV9O T0RFU1RfQ09OTj0yMywNCiAJTkVUX0lQVjRfVlNfU1lOQ19USFJFU0hPTEQ9 MjQsDQogCU5FVF9JUFY0X1ZTX05BVF9JQ01QX1NFTkQ9MjUsDQorCU5FVF9J UFY0X1ZTX0VYUElSRV9RVUlFU0NFTlRfVEVNUExBVEU9MjYsDQogCU5FVF9J UFY0X1ZTX0xBU1QNCiB9Ow0KIA0KQEAgLTcwMCw2ICs3MDEsNyBAQA0KICAq Lw0KIGV4dGVybiBpbnQgc3lzY3RsX2lwX3ZzX2NhY2hlX2J5cGFzczsNCiBl eHRlcm4gaW50IHN5c2N0bF9pcF92c19leHBpcmVfbm9kZXN0X2Nvbm47DQor ZXh0ZXJuIGludCBzeXNjdGxfaXBfdnNfZXhwaXJlX3F1aWVzY2VudF90ZW1w bGF0ZTsNCiBleHRlcm4gaW50IHN5c2N0bF9pcF92c19zeW5jX3RocmVzaG9s ZDsNCiBleHRlcm4gaW50IHN5c2N0bF9pcF92c19uYXRfaWNtcF9zZW5kOw0K IGV4dGVybiBzdHJ1Y3QgaXBfdnNfc3RhdHMgaXBfdnNfc3RhdHM7DQpkaWZm IC1OcnUgYS9uZXQvaXB2NC9pcHZzL2lwX3ZzX2Nvbm4uYyBiL25ldC9pcHY0 L2lwdnMvaXBfdnNfY29ubi5jDQotLS0gYS9uZXQvaXB2NC9pcHZzL2lwX3Zz X2Nvbm4uYwkyMDA0LTEyLTAyIDAwOjE2OjM2ICswODowMA0KKysrIGIvbmV0 L2lwdjQvaXB2cy9pcF92c19jb25uLmMJMjAwNC0xMi0wMiAwMDoxNjozNiAr MDg6MDANCkBAIC0xMTMxLDcgKzExMzEsOSBAQA0KIAkgKiBDaGVja2luZyB0 aGUgZGVzdCBzZXJ2ZXIgc3RhdHVzLg0KIAkgKi8NCiAJaWYgKChkZXN0ID09 IE5VTEwpIHx8DQotCSAgICAhKGRlc3QtPmZsYWdzICYgSVBfVlNfREVTVF9G X0FWQUlMQUJMRSkpIHsNCisJICAgICEoZGVzdC0+ZmxhZ3MgJiBJUF9WU19E RVNUX0ZfQVZBSUxBQkxFKSB8fCANCisJICAgIChzeXNjdGxfaXBfdnNfZXhw aXJlX3F1aWVzY2VudF90ZW1wbGF0ZSAmJiANCisJICAgICAoYXRvbWljX3Jl YWQoJmRlc3QtPndlaWdodCkgPT0gMCkpKSB7DQogCQlJUF9WU19EQkcoOSwg ImNoZWNrX3RlbXBsYXRlOiBkZXN0IG5vdCBhdmFpbGFibGUgZm9yICINCiAJ CQkgICJwcm90b2NvbCAlcyBzOiV1LiV1LiV1LiV1OiVkIHY6JXUuJXUuJXUu JXU6JWQgIg0KIAkJCSAgIi0+IGQ6JXUuJXUuJXUuJXU6JWRcbiIsDQpkaWZm IC1OcnUgYS9uZXQvaXB2NC9pcHZzL2lwX3ZzX2N0bC5jIGIvbmV0L2lwdjQv aXB2cy9pcF92c19jdGwuYw0KLS0tIGEvbmV0L2lwdjQvaXB2cy9pcF92c19j dGwuYwkyMDA0LTEyLTAyIDAwOjE2OjM2ICswODowMA0KKysrIGIvbmV0L2lw djQvaXB2cy9pcF92c19jdGwuYwkyMDA0LTEyLTAyIDAwOjE2OjM2ICswODow MA0KQEAgLTc0LDYgKzc0LDcgQEANCiBzdGF0aWMgaW50IHN5c2N0bF9pcF92 c19hbV9kcm9wcmF0ZSA9IDEwOw0KIGludCBzeXNjdGxfaXBfdnNfY2FjaGVf YnlwYXNzID0gMDsNCiBpbnQgc3lzY3RsX2lwX3ZzX2V4cGlyZV9ub2Rlc3Rf Y29ubiA9IDA7DQoraW50IHN5c2N0bF9pcF92c19leHBpcmVfcXVpZXNjZW50 X3RlbXBsYXRlID0gMDsNCiBpbnQgc3lzY3RsX2lwX3ZzX3N5bmNfdGhyZXNo b2xkID0gMzsNCiBpbnQgc3lzY3RsX2lwX3ZzX25hdF9pY21wX3NlbmQgPSAw Ow0KIA0KQEAgLTE0MzksNiArMTQ0MCw5IEBADQogCSAgJnByb2NfZG9pbnR2 ZWN9LA0KIAkge05FVF9JUFY0X1ZTX05BVF9JQ01QX1NFTkQsICJuYXRfaWNt cF9zZW5kIiwNCiAJICAmc3lzY3RsX2lwX3ZzX25hdF9pY21wX3NlbmQsIHNp emVvZihpbnQpLCAwNjQ0LCBOVUxMLA0KKwkgICZwcm9jX2RvaW50dmVjfSwN CisJIHtORVRfSVBWNF9WU19FWFBJUkVfUVVJRVNDRU5UX1RFTVBMQVRFLCAi ZXhwaXJlX3F1aWVzY2VudF90ZW1wbGF0ZSIsDQorCSAgJnN5c2N0bF9pcF92 c19leHBpcmVfcXVpZXNjZW50X3RlbXBsYXRlLCBzaXplb2YoaW50KSwgMDY0 NCwgTlVMTCwNCiAJICAmcHJvY19kb2ludHZlY30sDQogCSB7MH19LA0KIAl7 e05FVF9JUFY0X1ZTLCAidnMiLCBOVUxMLCAwLCAwNTU1LCBpcHY0X3ZzX3Rh YmxlLnZzX3ZhcnN9LA0K ---1463811584-572891765-1097000265=:2451 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="linux-2.6-ipvs-quiescent_template.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="linux-2.6-ipvs-quiescent_template.patch" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBkaWZmIC1OcnUgc3R5 bGUgcGF0Y2guDQojDQojIENoYW5nZVNldA0KIyAgIDIwMDQvMTIvMDIgMDA6 NDI6MTUrMDg6MDAgd2Vuc29uZ0BsaW51eC12cy5vcmcgDQojICAgW0lQVlNd IGFkZCBhIHN5c2N0bCB2YXJpYWJsZSB0byBleHBpcmUgcXVpZXNjZW50IHRl bXBsYXRlDQojICAgDQojICAgVGhlIHBhdGNoIGlzIGZyb20gSG9ybXMgPGhv cm1zQHZlcmdlbmV0Lm5ldD4NCiMgDQojIG5ldC9pcHY0L2lwdnMvaXBfdnNf Y3RsLmMNCiMgICAyMDA0LzEyLzAyIDAwOjQxOjU2KzA4OjAwIHdlbnNvbmdA bGludXgtdnMub3JnICsyMCAtMTENCiMgICBzZXQgdGhlIHN5c2N0bF9pcF92 c19leHBpcmVfcXVpZXNjZW50X3RlbXBsYXRlDQojIA0KIyBuZXQvaXB2NC9p cHZzL2lwX3ZzX2Nvbm4uYw0KIyAgIDIwMDQvMTIvMDIgMDA6NDE6NTYrMDg6 MDAgd2Vuc29uZ0BsaW51eC12cy5vcmcgKzMgLTENCiMgICBkb24ndCB1c2Ug cXVpZXNjZW50IHRlbXBsYXRlIGlmIHRoZSBleHBpcmVfcXVpZXNjZW50X3Rl bXBsYXRlIGlzIGVuYWJsZWQNCiMgDQojIGluY2x1ZGUvbmV0L2lwX3ZzLmgN CiMgICAyMDA0LzEyLzAyIDAwOjQxOjU2KzA4OjAwIHdlbnNvbmdAbGludXgt dnMub3JnICsyIC0wDQojICAgYWRkIHRoZSBzeXNjdGxfaXBfdnNfZXhwaXJl X3F1aWVzY2VudF90ZW1wbGF0ZSBwcm90b3R5cGUNCiMgDQpkaWZmIC1OcnUg YS9pbmNsdWRlL25ldC9pcF92cy5oIGIvaW5jbHVkZS9uZXQvaXBfdnMuaA0K LS0tIGEvaW5jbHVkZS9uZXQvaXBfdnMuaAkyMDA0LTEyLTAyIDAwOjQzOjE0 ICswODowMA0KKysrIGIvaW5jbHVkZS9uZXQvaXBfdnMuaAkyMDA0LTEyLTAy IDAwOjQzOjE0ICswODowMA0KQEAgLTM1OCw2ICszNTgsNyBAQA0KIAlORVRf SVBWNF9WU19FWFBJUkVfTk9ERVNUX0NPTk49MjMsDQogCU5FVF9JUFY0X1ZT X1NZTkNfVEhSRVNIT0xEPTI0LA0KIAlORVRfSVBWNF9WU19OQVRfSUNNUF9T RU5EPTI1LA0KKwlORVRfSVBWNF9WU19FWFBJUkVfUVVJRVNDRU5UX1RFTVBM QVRFPTI2LA0KIAlORVRfSVBWNF9WU19MQVNUDQogfTsNCiANCkBAIC04Nzks NiArODgwLDcgQEANCiAgKi8NCiBleHRlcm4gaW50IHN5c2N0bF9pcF92c19j YWNoZV9ieXBhc3M7DQogZXh0ZXJuIGludCBzeXNjdGxfaXBfdnNfZXhwaXJl X25vZGVzdF9jb25uOw0KK2V4dGVybiBpbnQgc3lzY3RsX2lwX3ZzX2V4cGly ZV9xdWllc2NlbnRfdGVtcGxhdGU7DQogZXh0ZXJuIGludCBzeXNjdGxfaXBf dnNfc3luY190aHJlc2hvbGRbMl07DQogZXh0ZXJuIGludCBzeXNjdGxfaXBf dnNfbmF0X2ljbXBfc2VuZDsNCiBleHRlcm4gc3RydWN0IGlwX3ZzX3N0YXRz IGlwX3ZzX3N0YXRzOw0KZGlmZiAtTnJ1IGEvbmV0L2lwdjQvaXB2cy9pcF92 c19jb25uLmMgYi9uZXQvaXB2NC9pcHZzL2lwX3ZzX2Nvbm4uYw0KLS0tIGEv bmV0L2lwdjQvaXB2cy9pcF92c19jb25uLmMJMjAwNC0xMi0wMiAwMDo0Mzox NCArMDg6MDANCisrKyBiL25ldC9pcHY0L2lwdnMvaXBfdnNfY29ubi5jCTIw MDQtMTItMDIgMDA6NDM6MTQgKzA4OjAwDQpAQCAtNDUzLDcgKzQ1Myw5IEBA DQogCSAqIENoZWNraW5nIHRoZSBkZXN0IHNlcnZlciBzdGF0dXMuDQogCSAq Lw0KIAlpZiAoKGRlc3QgPT0gTlVMTCkgfHwNCi0JICAgICEoZGVzdC0+Zmxh Z3MgJiBJUF9WU19ERVNUX0ZfQVZBSUxBQkxFKSkgew0KKwkgICAgIShkZXN0 LT5mbGFncyAmIElQX1ZTX0RFU1RfRl9BVkFJTEFCTEUpIHx8IA0KKwkgICAg KHN5c2N0bF9pcF92c19leHBpcmVfcXVpZXNjZW50X3RlbXBsYXRlICYmIA0K KwkgICAgIChhdG9taWNfcmVhZCgmZGVzdC0+d2VpZ2h0KSA9PSAwKSkpIHsN CiAJCUlQX1ZTX0RCRyg5LCAiY2hlY2tfdGVtcGxhdGU6IGRlc3Qgbm90IGF2 YWlsYWJsZSBmb3IgIg0KIAkJCSAgInByb3RvY29sICVzIHM6JXUuJXUuJXUu JXU6JWQgdjoldS4ldS4ldS4ldTolZCAiDQogCQkJICAiLT4gZDoldS4ldS4l dS4ldTolZFxuIiwNCmRpZmYgLU5ydSBhL25ldC9pcHY0L2lwdnMvaXBfdnNf Y3RsLmMgYi9uZXQvaXB2NC9pcHZzL2lwX3ZzX2N0bC5jDQotLS0gYS9uZXQv aXB2NC9pcHZzL2lwX3ZzX2N0bC5jCTIwMDQtMTItMDIgMDA6NDM6MTQgKzA4 OjAwDQorKysgYi9uZXQvaXB2NC9pcHZzL2lwX3ZzX2N0bC5jCTIwMDQtMTIt MDIgMDA6NDM6MTQgKzA4OjAwDQpAQCAtNzUsNiArNzUsNyBAQA0KIHN0YXRp YyBpbnQgc3lzY3RsX2lwX3ZzX2FtX2Ryb3ByYXRlID0gMTA7DQogaW50IHN5 c2N0bF9pcF92c19jYWNoZV9ieXBhc3MgPSAwOw0KIGludCBzeXNjdGxfaXBf dnNfZXhwaXJlX25vZGVzdF9jb25uID0gMDsNCitpbnQgc3lzY3RsX2lwX3Zz X2V4cGlyZV9xdWllc2NlbnRfdGVtcGxhdGUgPSAwOw0KIGludCBzeXNjdGxf aXBfdnNfc3luY190aHJlc2hvbGRbMl0gPSB7IDMsIDUwIH07DQogaW50IHN5 c2N0bF9pcF92c19uYXRfaWNtcF9zZW5kID0gMDsNCiANCkBAIC0xNDQ3LDkg KzE0NDgsOSBAQA0KIAl7DQogCQkuY3RsX25hbWUJPSBORVRfSVBWNF9WU19U T19FUywNCiAJCS5wcm9jbmFtZQk9ICJ0aW1lb3V0X2VzdGFibGlzaGVkIiwN Ci0JICAJLmRhdGEJPSAmdnNfdGltZW91dF90YWJsZV9kb3MudGltZW91dFtJ UF9WU19TX0VTVEFCTElTSEVEXSwNCisJCS5kYXRhCT0gJnZzX3RpbWVvdXRf dGFibGVfZG9zLnRpbWVvdXRbSVBfVlNfU19FU1RBQkxJU0hFRF0sDQogCQku bWF4bGVuCQk9IHNpemVvZihpbnQpLA0KLQkJLm1vZGUJCT0gMDY0NCwgDQor CQkubW9kZQkJPSAwNjQ0LA0KIAkJLnByb2NfaGFuZGxlcgk9ICZwcm9jX2Rv aW50dmVjX2ppZmZpZXMsDQogCX0sDQogCXsNCkBAIC0xNDU3LDcgKzE0NTgs NyBAQA0KIAkJLnByb2NuYW1lCT0gInRpbWVvdXRfc3luc2VudCIsDQogCQku ZGF0YQk9ICZ2c190aW1lb3V0X3RhYmxlX2Rvcy50aW1lb3V0W0lQX1ZTX1Nf U1lOX1NFTlRdLA0KIAkJLm1heGxlbgkJPSBzaXplb2YoaW50KSwNCi0JCS5t b2RlCQk9IDA2NDQsIA0KKwkJLm1vZGUJCT0gMDY0NCwNCiAJCS5wcm9jX2hh bmRsZXIJPSAmcHJvY19kb2ludHZlY19qaWZmaWVzLA0KIAl9LA0KIAl7DQpA QCAtMTQ2NSw3ICsxNDY2LDcgQEANCiAJCS5wcm9jbmFtZQk9ICJ0aW1lb3V0 X3N5bnJlY3YiLA0KIAkJLmRhdGEJPSAmdnNfdGltZW91dF90YWJsZV9kb3Mu dGltZW91dFtJUF9WU19TX1NZTl9SRUNWXSwNCiAJCS5tYXhsZW4JCT0gc2l6 ZW9mKGludCksDQotCQkubW9kZQkJPSAwNjQ0LCANCisJCS5tb2RlCQk9IDA2 NDQsDQogCQkucHJvY19oYW5kbGVyCT0gJnByb2NfZG9pbnR2ZWNfamlmZmll cywNCiAJfSwNCiAJew0KQEAgLTE0NzMsNyArMTQ3NCw3IEBADQogCQkucHJv Y25hbWUJPSAidGltZW91dF9maW53YWl0IiwNCiAJCS5kYXRhCT0gJnZzX3Rp bWVvdXRfdGFibGVfZG9zLnRpbWVvdXRbSVBfVlNfU19GSU5fV0FJVF0sDQog CQkubWF4bGVuCQk9IHNpemVvZihpbnQpLA0KLQkJLm1vZGUJCT0gMDY0NCwg DQorCQkubW9kZQkJPSAwNjQ0LA0KIAkJLnByb2NfaGFuZGxlcgk9ICZwcm9j X2RvaW50dmVjX2ppZmZpZXMsDQogCX0sDQogCXsNCkBAIC0xNDg5LDcgKzE0 OTAsNyBAQA0KIAkJLnByb2NuYW1lCT0gInRpbWVvdXRfY2xvc2UiLA0KIAkJ LmRhdGEJPSAmdnNfdGltZW91dF90YWJsZV9kb3MudGltZW91dFtJUF9WU19T X0NMT1NFXSwNCiAJCS5tYXhsZW4JCT0gc2l6ZW9mKGludCksDQotCQkubW9k ZQkJPSAwNjQ0LCANCisJCS5tb2RlCQk9IDA2NDQsDQogCQkucHJvY19oYW5k bGVyCT0gJnByb2NfZG9pbnR2ZWNfamlmZmllcywNCiAJfSwNCiAJew0KQEAg LTE0OTcsNyArMTQ5OCw3IEBADQogCQkucHJvY25hbWUJPSAidGltZW91dF9j bG9zZXdhaXQiLA0KIAkJLmRhdGEJPSAmdnNfdGltZW91dF90YWJsZV9kb3Mu dGltZW91dFtJUF9WU19TX0NMT1NFX1dBSVRdLA0KIAkJLm1heGxlbgkJPSBz aXplb2YoaW50KSwNCi0JCS5tb2RlCQk9IDA2NDQsIA0KKwkJLm1vZGUJCT0g MDY0NCwNCiAJCS5wcm9jX2hhbmRsZXIJPSAmcHJvY19kb2ludHZlY19qaWZm aWVzLA0KIAl9LA0KIAl7DQpAQCAtMTUwNSw3ICsxNTA2LDcgQEANCiAJCS5w cm9jbmFtZQk9ICJ0aW1lb3V0X2xhc3RhY2siLA0KIAkJLmRhdGEJPSAmdnNf dGltZW91dF90YWJsZV9kb3MudGltZW91dFtJUF9WU19TX0xBU1RfQUNLXSwN CiAJCS5tYXhsZW4JCT0gc2l6ZW9mKGludCksDQotCQkubW9kZQkJPSAwNjQ0 LCANCisJCS5tb2RlCQk9IDA2NDQsDQogCQkucHJvY19oYW5kbGVyCT0gJnBy b2NfZG9pbnR2ZWNfamlmZmllcywNCiAJfSwNCiAJew0KQEAgLTE1MTMsNyAr MTUxNCw3IEBADQogCQkucHJvY25hbWUJPSAidGltZW91dF9saXN0ZW4iLA0K IAkJLmRhdGEJPSAmdnNfdGltZW91dF90YWJsZV9kb3MudGltZW91dFtJUF9W U19TX0xJU1RFTl0sDQogCQkubWF4bGVuCQk9IHNpemVvZihpbnQpLA0KLQkJ Lm1vZGUJCT0gMDY0NCwgDQorCQkubW9kZQkJPSAwNjQ0LA0KIAkJLnByb2Nf aGFuZGxlcgk9ICZwcm9jX2RvaW50dmVjX2ppZmZpZXMsDQogCX0sDQogCXsN CkBAIC0xNTIxLDcgKzE1MjIsNyBAQA0KIAkJLnByb2NuYW1lCT0gInRpbWVv dXRfc3luYWNrIiwNCiAJCS5kYXRhCT0gJnZzX3RpbWVvdXRfdGFibGVfZG9z LnRpbWVvdXRbSVBfVlNfU19TWU5BQ0tdLA0KIAkJLm1heGxlbgkJPSBzaXpl b2YoaW50KSwNCi0JCS5tb2RlCQk9IDA2NDQsIA0KKwkJLm1vZGUJCT0gMDY0 NCwNCiAJCS5wcm9jX2hhbmRsZXIJPSAmcHJvY19kb2ludHZlY19qaWZmaWVz LA0KIAl9LA0KIAl7DQpAQCAtMTUyOSw3ICsxNTMwLDcgQEANCiAJCS5wcm9j bmFtZQk9ICJ0aW1lb3V0X3VkcCIsDQogCQkuZGF0YQk9ICZ2c190aW1lb3V0 X3RhYmxlX2Rvcy50aW1lb3V0W0lQX1ZTX1NfVURQXSwNCiAJCS5tYXhsZW4J CT0gc2l6ZW9mKGludCksDQotCQkubW9kZQkJPSAwNjQ0LCANCisJCS5tb2Rl CQk9IDA2NDQsDQogCQkucHJvY19oYW5kbGVyCT0gJnByb2NfZG9pbnR2ZWNf amlmZmllcywNCiAJfSwNCiAJew0KQEAgLTE1NTMsNiArMTU1NCwxNCBAQA0K IAkJLmN0bF9uYW1lCT0gTkVUX0lQVjRfVlNfRVhQSVJFX05PREVTVF9DT05O LA0KIAkJLnByb2NuYW1lCT0gImV4cGlyZV9ub2Rlc3RfY29ubiIsDQogCQku ZGF0YQkJPSAmc3lzY3RsX2lwX3ZzX2V4cGlyZV9ub2Rlc3RfY29ubiwNCisJ CS5tYXhsZW4JCT0gc2l6ZW9mKGludCksDQorCQkubW9kZQkJPSAwNjQ0LA0K KwkJLnByb2NfaGFuZGxlcgk9ICZwcm9jX2RvaW50dmVjLA0KKwl9LA0KKwl7 DQorCQkuY3RsX25hbWUJPSBORVRfSVBWNF9WU19FWFBJUkVfUVVJRVNDRU5U X1RFTVBMQVRFLA0KKwkJLnByb2NuYW1lCT0gImV4cGlyZV9xdWllc2NlbnRf dGVtcGxhdGUiLA0KKwkJLmRhdGEJCT0gJnN5c2N0bF9pcF92c19leHBpcmVf cXVpZXNjZW50X3RlbXBsYXRlLA0KIAkJLm1heGxlbgkJPSBzaXplb2YoaW50 KSwNCiAJCS5tb2RlCQk9IDA2NDQsDQogCQkucHJvY19oYW5kbGVyCT0gJnBy b2NfZG9pbnR2ZWMsDQo= ---1463811584-572891765-1097000265=:2451-- From Robert.Olsson@data.slu.se Wed Dec 1 09:38:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Dec 2004 09:38:10 -0800 (PST) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB1Hc487020583 for ; Wed, 1 Dec 2004 09:38:06 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id iB1HbaKO016341; Wed, 1 Dec 2004 18:37:37 +0100 Received: by robur.slu.se (Postfix, from userid 1000) id 0CEF4EC001; Wed, 1 Dec 2004 18:37:37 +0100 (CET) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16814.353.15446.489489@robur.slu.se> Date: Wed, 1 Dec 2004 18:37:37 +0100 To: sfeldma@pobox.com Cc: Robert Olsson , Lennert Buytenhek , jamal , P@draigBrady.com, mellia@prezzemolo.polito.it, e1000-devel@lists.sourceforge.net, Jorge Manuel Finochietto , Giulio Galante , netdev@oss.sgi.com Subject: Re: [E1000-devel] Transmission limit In-Reply-To: <1101919791.5198.15.camel@localhost.localdomain> References: <1101467291.24742.70.camel@mellia.lipar.polito.it> <41A73826.3000109@draigBrady.com> <16807.20052.569125.686158@robur.slu.se> <1101484740.24742.213.camel@mellia.lipar.polito.it> <41A76085.7000105@draigBrady.com> <1101499285.1079.45.camel@jzny.localdomain> <16811.8052.678955.795327@robur.slu.se> <1101821501.1043.43.camel@jzny.localdomain> <20041130134600.GA31515@xi.wantstofly.org> <1101824754.1044.126.camel@jzny.localdomain> <20041201001107.GE4203@xi.wantstofly.org> <1101863399.4663.54.camel@sfeldma-mobl.dsl-verizon.net> <16813.58484.343629.570703@robur.slu.se> <1101919791.5198.15.camel@localhost.localdomain> X-Mailer: VM 7.18 under Emacs 21.3.1 X-archive-position: 12370 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 Scott Feldman writes: > Thank you Robert for trying it out. > > Well those results are counter-intuitive! We remove Tx interrupts and > Tx descriptor DMA write-backs and get no re-tries, and performance > drops? The only bus activities left are the DMA of buffers to device > and the register writes to increment tail. I'm stumped. I'll need to > get my hands on a faster system. Maybe there is a bus analyzer under > the tree. :-) Huh. I've got a deja-vu feeling. What will happen if we remove almost all events (interrupts) and just have the timer waking up once-in-a-while? --ro From buytenh@wantstofly.org Wed Dec 1 10:30:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Dec 2004 10:30:14 -0800 (PST) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB1IU5tj022456 for ; Wed, 1 Dec 2004 10:30:09 -0800 Received: by xi.wantstofly.org (Postfix, from userid 500) id 80D2B2B0ED; Wed, 1 Dec 2004 19:29:43 +0100 (MET) Date: Wed, 1 Dec 2004 19:29:43 +0100 From: Lennert Buytenhek To: Scott Feldman Cc: jamal , Robert Olsson , P@draigBrady.com, mellia@prezzemolo.polito.it, e1000-devel@lists.sourceforge.net, Jorge Manuel Finochietto , Giulio Galante , netdev@oss.sgi.com Subject: Re: [E1000-devel] Transmission limit Message-ID: <20041201182943.GA14470@xi.wantstofly.org> References: <16807.20052.569125.686158@robur.slu.se> <1101484740.24742.213.camel@mellia.lipar.polito.it> <41A76085.7000105@draigBrady.com> <1101499285.1079.45.camel@jzny.localdomain> <16811.8052.678955.795327@robur.slu.se> <1101821501.1043.43.camel@jzny.localdomain> <20041130134600.GA31515@xi.wantstofly.org> <1101824754.1044.126.camel@jzny.localdomain> <20041201001107.GE4203@xi.wantstofly.org> <1101863399.4663.54.camel@sfeldma-mobl.dsl-verizon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1101863399.4663.54.camel@sfeldma-mobl.dsl-verizon.net> User-Agent: Mutt/1.4.1i X-archive-position: 12371 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev On Tue, Nov 30, 2004 at 05:09:59PM -0800, Scott Feldman wrote: > This doubles the kpps numbers for 60-byte packets. I'd like to see what > happens on higher bus bandwidth systems. Anyone? Dual Xeon 2.4GHz, a 82540EM and a 82541GI both on 32/66 on separate PCI buses. BEFORE performance is approx the same for both, ~620kpps. AFTER performance is ~730kpps, also approx the same for both. (Note: only sending with one NIC at a time.) Once or twice it went into a state where it started spitting out these kinds of messages and never recovered: Dec 1 19:13:18 phi kernel: NETDEV WATCHDOG: eth1: transmit timed out [...] Dec 1 19:13:31 phi kernel: NETDEV WATCHDOG: eth1: transmit timed out [...] Dec 1 19:13:43 phi kernel: NETDEV WATCHDOG: eth1: transmit timed out But overall, looks good. Strange thing that Robert's numbers didn't improve. Doing some more measurements right now. --L From buytenh@wantstofly.org Wed Dec 1 11:56:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Dec 2004 11:56:17 -0800 (PST) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB1JuBrN024519 for ; Wed, 1 Dec 2004 11:56:12 -0800 Received: by xi.wantstofly.org (Postfix, from userid 500) id 5BE772B100; Wed, 1 Dec 2004 20:55:50 +0100 (MET) Date: Wed, 1 Dec 2004 20:55:50 +0100 From: Lennert Buytenhek To: Ben Greear Cc: netdev@oss.sgi.com Subject: Re: via-rhine unable to send back-to-back packets? Message-ID: <20041201195550.GC14470@xi.wantstofly.org> References: <20041129222700.GA22918@xi.wantstofly.org> <20041129172540.6b959858.davem@davemloft.net> <20041130064823.GA27872@xi.wantstofly.org> <41ACB0C3.5020408@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41ACB0C3.5020408@candelatech.com> User-Agent: Mutt/1.4.1i X-archive-position: 12372 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev On Tue, Nov 30, 2004 at 09:41:23AM -0800, Ben Greear wrote: > >Yeah, preamble (8 bytes), CRC (4 bytes), inter-packet gap (12 bytes). > > > >Perhaps the via-rhine simply can't send out packets back-to-back and > >needs 14 byte times of inter-packet gap. I couldn't find any stray +2 > >in the driver anywhere but I'm just checking. > > Couldn't you just sniff the resulting traffic to see if it is too big? Sorry, forgot to mention: I did check that, and the data portion of the packet doesn't appear to be too big. --L From buytenh@wantstofly.org Wed Dec 1 12:02:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Dec 2004 12:02:15 -0800 (PST) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB1K2AuT024983 for ; Wed, 1 Dec 2004 12:02:10 -0800 Received: by xi.wantstofly.org (Postfix, from userid 500) id 088982B100; Wed, 1 Dec 2004 21:01:49 +0100 (MET) Date: Wed, 1 Dec 2004 21:01:48 +0100 From: Lennert Buytenhek To: Roger Luethi Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: via-rhine unable to send back-to-back packets? Message-ID: <20041201200148.GE14470@xi.wantstofly.org> References: <20041129222700.GA22918@xi.wantstofly.org> <20041129172540.6b959858.davem@davemloft.net> <20041130064823.GA27872@xi.wantstofly.org> <20041130122503.0adac947.davem@davemloft.net> <20041130220644.GC29947@k3.hellgate.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041130220644.GC29947@k3.hellgate.ch> User-Agent: Mutt/1.4.1i X-archive-position: 12373 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev On Tue, Nov 30, 2004 at 11:06:44PM +0100, Roger Luethi wrote: > > > Perhaps the via-rhine simply can't send out packets back-to-back and > > > needs 14 byte times of inter-packet gap. I couldn't find any stray +2 > > > in the driver anywhere but I'm just checking. > > > > Or the via-rhine driver is not programming one of the registers > > proper to get optimal spacing. > > > > As with most Donald Becker drivers, many of the register layouts > > are not documented in the sources so it's not possible to just > > scan the driver looking for potential problems like this. > > For example, maybe the TxConfig register has an "IPG" field but > > we'll never know by reading anything in the driver source. > > Presumably Donald Becker had only access to the publicly available > documentation at the time which is very incomplete and buggy. What > little time my day job leaves for hacking via-rhine is consumed by the > WOL issues that have come up with 2.6.9+, but if you have a specific > question that can be answered by someone who knows the chip but not > necessarily Linux I can try and poke my contacts. "Is the hardware capable of sending back-to-back packets (i.e. with an inter-packet gap of no more than 96 bit times)?" "Can misprogramming the chip lead to the effect that the inter-packet gap is never less than 112 bit times?" Thanks in advance. > Of course, you can always check if VIA's driver has the same issue. If > it doesn't, chances are we can borrow the fix. Hmm, didn't know they had such a driver. Where can I find it? cheers, Lennert From buytenh@wantstofly.org Wed Dec 1 13:36:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Dec 2004 13:36:20 -0800 (PST) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB1LaBxK001792 for ; Wed, 1 Dec 2004 13:36:14 -0800 Received: by xi.wantstofly.org (Postfix, from userid 500) id 549B22B100; Wed, 1 Dec 2004 22:35:50 +0100 (MET) Date: Wed, 1 Dec 2004 22:35:50 +0100 From: Lennert Buytenhek To: Scott Feldman Cc: jamal , Robert Olsson , P@draigBrady.com, mellia@prezzemolo.polito.it, e1000-devel@lists.sourceforge.net, Jorge Manuel Finochietto , Giulio Galante , netdev@oss.sgi.com Subject: Re: [E1000-devel] Transmission limit Message-ID: <20041201213550.GF14470@xi.wantstofly.org> References: <1101484740.24742.213.camel@mellia.lipar.polito.it> <41A76085.7000105@draigBrady.com> <1101499285.1079.45.camel@jzny.localdomain> <16811.8052.678955.795327@robur.slu.se> <1101821501.1043.43.camel@jzny.localdomain> <20041130134600.GA31515@xi.wantstofly.org> <1101824754.1044.126.camel@jzny.localdomain> <20041201001107.GE4203@xi.wantstofly.org> <1101863399.4663.54.camel@sfeldma-mobl.dsl-verizon.net> <20041201182943.GA14470@xi.wantstofly.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="uZ3hkaAS1mZxFaxD" Content-Disposition: inline In-Reply-To: <20041201182943.GA14470@xi.wantstofly.org> User-Agent: Mutt/1.4.1i X-archive-position: 12374 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev --uZ3hkaAS1mZxFaxD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Dec 01, 2004 at 07:29:43PM +0100, Lennert Buytenhek wrote: > > This doubles the kpps numbers for 60-byte packets. I'd like to see what > > happens on higher bus bandwidth systems. Anyone? > > Dual Xeon 2.4GHz, a 82540EM and a 82541GI both on 32/66 on separate > PCI buses. > > BEFORE performance is approx the same for both, ~620kpps. > AFTER performance is ~730kpps, also approx the same for both. Pretty graph attached. From ~220B packets or so it does wire speed, but there's still an odd drop in performance around 256B packets (which is also there without your patch.) From 350B packets or so, performance is identical with or without your patch (wire speed.) So. Do you have any other good plans perhaps? :) > Once or twice it went into a state where it started spitting out these > kinds of messages and never recovered: > > Dec 1 19:13:18 phi kernel: NETDEV WATCHDOG: eth1: transmit timed out > [...] > Dec 1 19:13:31 phi kernel: NETDEV WATCHDOG: eth1: transmit timed out > [...] > Dec 1 19:13:43 phi kernel: NETDEV WATCHDOG: eth1: transmit timed out Didn't see this happen anymore. (ifconfig down and then up recovered it both times I saw it happen.) thanks, Lennert --uZ3hkaAS1mZxFaxD Content-Type: image/png Content-Disposition: attachment; filename="feldman.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAoAAAAHPCAIAAABMSfxQAAAACXBIWXMAAAsTAAALEwEAmpwY AAAAB3RJTUUH1AwBFR0dvrAfowAAHrZJREFUeNrt3e1yqjoYBtB4Zt9Euf9ro5fh+UFLYxJC VJCvtWbPHkqVirY+vklIbn3fBwDgs/7zFACAAAYAAdym67rZGwzePPLLxwGAvfn3gfQdu5nj 7ZYj930/3uXl4wDA2SrgZ4OwfuM4y8cjDxn81HEA4OQV8MtBOGaqKAVAAK8lidu8MXm8wbAx lcqzsa17GIDPeL+A/PfJRxl36OY3mG3QrvcBS18APub90Uj/Nnnc67U8X6RNu95U4EydrJN1 pk72A2f6pv+2fWTxLePXbGyXNuAZgFN6qwIu9t0mwRl38U7tmapl4/RtvBcAHMJtjTDbpGy9 VDsPABtaJHFWaYKWgsAn3wfXGIO5q3n3Vn0ke5thMJ/0cL1XeVvmggZoKiTOeqlFY8m01OnX jzM0oA5Of22LAAZgsZz+2HFO4J+nADh6KhTn9ol3Jm/9s7MDTdVts0euFHzxMNVkovv2cEoe an4WyZDYlmejvWyN79LyrObnNXuc4qOqfOspX133vaf4F8DAqSQruBSn3nthZZfkjqE6qV/x Lsm1IfF3Z48z9ROLp1zZaP+okYdfcbr+5Lxa9swe59mXRgUMsKOauFiZxbk4bLzzFp8fJz/a az9rKheT/ZWFavKNyr1afnp7lfz+C7dG+n79PrZhYyd1sAAGrhLJyZ733+VbjrPgz0oO8toB Vyori23j7x9qKUPi7q0J2iAs4CqSq1nyxt7G5Jg9Tn7A+pje8cKb2fnwiwd5LfBWGmOctDC3 nFfyrF5nlJYKGDh5+Ts7GV/cUJxM8Fecj699Ur+p2yS3f6p1erxQ54XhVMV7tSRf+xSH9Qc2 e5zw5Ki0F+rg/bid5rOGmbCAg753nfKN69y17H5nwgIABDDAfp21TNQeKYABQAADB2fxg5Od 6csPsnKD9y9DshgDwOdY/GCl03/hOPlA65fP4uUfbTEGAHad06seRz/uqlwHDDz9jmzxg3CW xQ+eLaNbnvnkRz/1HK60GEP31fXffb4tgIEDs/hBOPLiB1MTZecfLGbPopiy9We+uPHsr0rT r9N3P+TuftJXAAPL1MTB4gcTh9r54gdTz+HsuS/1mBuf/AUzeD9/OwIYWCuSkz0WP1ij4SF8 ZLTaImfR+JhXmkJrhxWwQVjAWix+sEYRWTnsC4sfbHIWW6XvWAergIFzlr8WP6g/nr0tfrDI WUx9WElehfwx1+N5saHgUdW7nwrYYgzA5epyix+wh8TRBA0AGxDAwLVY/AABDMDZrDRPuAAG YJskS5Yo6B5Vsmq9Pfn+F/qh81PID3vWeaEFMMAB0jdfoqCPxDfLE3GNPUud5nWWXhDAyWv/ 5e8c2GH6vtChm18RtN6e4kNd8Prj4oRZliMEYF1TU4kVg2q3sVRvGK+c13Wup/rv2r/l34pg 4KDFccuqvRtW6nkBPX5cyD83XPMiZjNhARwvfTePq5bITObTnpqm+7X1sh6PsHwp1fffAhiA C03gFY/0bl688vuI564PGODAKZWUm+Ejo7GK0Tg1RGtqueXiceJx3estD7wTV6+Ah27gg356 As4at/HGmHlJSuULJBSXUFxpT/uHhvp911h64SgsxhAEMMB6xfo+j7lV4sQ0QQOwmDWS8qyV sQB2MRIAAhgABDAAIIBXpBUaAAEMAAIYABDAACCAT0U3MAACGAAEMAAggNejFRoAAQwAArgq X5bynZtV7tL9WvUZUQQDcIAAXi8Ok5Wchy+TVTAXZ11CAA4QwO1rNLZEZnybZCXnLCZ7rxwA 1w3g9vRNbvmZxuSXi2Ct0ACs7d/nf2Scx3k7cyXXx5tVgr/lNgDwWn4dKYCLzdTJOQw3mG3Q TmLbrwIAKuCmjwxxz+5KP2uRIw+t0AZkATBVB75/tFWuA44f2Th0uZiOyS3j7eFbil0AVMC1 0jZELcn14Iw7fSvhOtxsvEHjvRb9GKEIBmAttzXCbJOytT6ASwADsKvEWaUJWqMxAGwQwOfg gmAABDAACGAAQACvRys0AAIYAAQwACCA16MVGgABDAACGAAQwOvRCg2AAAYAAQwACOD1aIUG QAADgAAGAATwerRCAyCAAUAAAwACeD1aoQEQwAAggAEAAbwerdAACGAAEMBXoggGQAB/Wt9/ exIAEMAAIIAvUwRrhQZAAAOAAAYABPBKtEIDIIABQABfiSIYAAH8aS4IBkAAA4AAvlIRrBUa AAEMAAJYEQwAAhgABLAiGAABDAAIYEUwAAIYABDA+6YIBkAAf5qZKQEQwAAggK9UBGuFBkAA A4AAVgQDgAAGgGMHcNd1szcYvHnkl4/zeYpgAOr+fSB9+77Pt1uO3Pf9eJeXj/N5WqEBWLcC XjYI4ywfjzxkcJZwvVcOgOtWwC1BWLzNmKlnjdKhCDY1BwCrBPBr5XLemDzm8bAxlcotsX36 aAdgK8sOQvr3sQcdJ2JyDnkw14vpnfcBK4IB2EUA53m5XnwqfAFYO2IWKYVXuQ64OJxq9pbx zcZ26UMUu9WnwnBoAApu78TbVEty8cvKbRpL5/q96v3HGwawVmiAk1kkcW5rJNYmZes+A1gG AwjgolWaoHXEAsAGAczjxxETYwEggAFAACuCARDAAIAAVgQDIIBZhAwGQABvUAR7EgAQwIpg AASwIhgAAQwACOCzFcFaoQEQwAAggBXBAAhgAEAAK4IBEMAAgAA+KEUwgADm00zKASCAUQQD IIAVwQAIYBTBAAhgRTAAAhhFMAACWBEMgABGEQyAAFYEAyCAUQQDCGAUwQAI4GtnsCIYQAAD AAJYEQyAAEYGAyCAAUAAowgGQADLYAAEMAAggBXBAAhgimQwgABmgyLYkwAggNkmgxXBAAIY ABDAimAABDAAIIAVwQAIYJYggwEEMBsUwZ4EAAHMNhmsCAYQwADAvgO467r379X9UgT7xQUQ wCumb9/3432HLwcXz+BgNBaAAG7M0WdzerxXMW4bD3jiItgvLsDR/Vs/LfpK1l48St/J4K77 ksQAAvjFmjhvZ66kcktsi3YA1suvYwdwfg5DWM42ViexrQhWBAOogJ8Nj/5wR5bBAJevfPoF S+GNrwOOzyHOzrFdWrHb8BwaEQ2gAp6O2LF/N+70rYTrcLPxBo33ut7HMZcFAwjgasE+u3P2 ZnK3ksEaogGOxVSU6mAABDBvkMEAApgNimBPAoAAZpsMVgQDCGBkMAACGAAEMIpgAAHMCclg AAHMBkWwJwFAALNNBiuCAQQwACCAFcEACGBkMIAARgYDIIBZiAwGEMBsUATLYAABzGYZDIAA ZoMMVgQDCGBkMIAARgYDIICRwQACmHOSwQACmA2KYE8CgABmmwxWBAMIYGQwgABGBgMggFmb DAYQwGxQBHsSAAQw22SwIhhAALMNGQwggNmgCPYkAAhgtslgRTCAAEYGAwhgZDAAAhgZDCCA kcEACGBkMIAARgYDIICRwQACGBkMIIChTgYDCGA2KII9CQACmG0yWBEMIICRwQACGBkMgADm AxkshgEEMBtkcDAuGkAAs0kGa44GEMBsFsMyGGAvAdz9SnbmN1tkDzIYQACHruv6X2NYDjvj 7FxqDzIYQADXIjmEMGbnUnvYFRkMsK8A5iJFsCcB4Cn/ln4j/itPh4L143XYlj/94hncdV+S GDixZdtf/y3+4Mbki7eRwQCsGMA7yACRL4MB1o2YRUrh/z7wcJcde6WwPkQGex4A6m6Lh1mx FzZPzaX2JD9XNu+EOhg49VvcAolzO01iCWAZDHCgxHEZEmvRFg0ggJHBAAKY62WwGAYQwGyQ wcFclQACmE0yWHM0gABmsxiWwQACGBkMIICRwQACGGQwgABGBgMIYJDBAAKYE2SwGAYEMGyQ wcE0HYAAvqbuq+u+unwbGQywkn+XTdwQQv/dx1k7bvff1jTcLIOtYAiogE/9dv/dTyWu9N02 hnUJAwL4EhlcqYPZKoONjgYE8JnFnb5jEieVMUphAAG8fPomLc/j8KsxhiWxUhhgJRcdhBW3 Pyc749zVH7yTUtjILEAAXyKbn+oSHm4vqmUwwFNcB5x66sIk6fvJDPY8AAL45Ok7jsYqpmz8 rXH/2HA9bMTbnlUZDJDTBJ1WtMVUjtulk0yNq+T4lvk4L5bKYM3RgAr4/KVwMXSLyT2mb7FW ZqkMDiG4Qgk4gVvfnyQkuq4LIXz4dOKSN6mAZfDKL/dXHMkAh0scFfC76VsM45DNdsnipbAl HIBDE8BvZMBvxA4bcftzXBYHo7FWjmEt0oAAvm4MT/2fzK6V19DFbZ6NYaUwcDhGQa+bzcV1 D4sZnNTTPJvBQx2sSxhQAfOw3kNlKo/49tL3nQx2rTCgAibkfcB5QRwPnJ66zjhkPcrMlsLB 6GhABXzdJChNp1WsjGd7gqXvsxkcdAkDApg8ZfNwTQK7soEMBs7BRBz7iup6Se339fnfCsOy gJ0mjgp4X+lbTFlzerxTCrtKGNgng7B2ExXV1mbl7zsZrBQGdkgFfJjiOP8fpTAggFm3OI6X WppaD5HZDHahMLAfmqCPlMEh6ipO1iEu3ljD9VQpHFwoDKiAaVFceSmpgJM98RwgGrGLpbBq GBDAzKdvJYPD41pM4w2SKrnYlH3ZJBbDwLY0QR8hKqLllZI0zUO6ePdi+rZkcJ7r54vhMYM1 SgMqYOZL4amW55B1/VbSN7ll/mV9Gq8zlcIhBNUw8ElmwjpnTods+o7ZOrj4ZUt1fqYSWSkM fCxxNEGfsaSLauJkeyp9Q9aI3RLG52ugjieRFsPAqjRBXyKJw2NHcuMlxWO4ximbd0Wf8Hmz lgOwPk3QTDyfUfpWAv7EQ7TUwcCqiaMCplY91/N1HESdbBTr6SPWwWbOAtajD5j5GJ7K4GKP cn1ikNlQ32EMK4WBNSxfAXe/8mp9jT3vGCaJGjbiL2mP56nrmuKLjOOm7LhWTv7ttmg2ZQdw gADuuq7/NYblsDPOzqX2sK3GK5qG7XqH8f67k8UwsPcKOHrD6sfUHL4csnOpPYvUvnH5G39L Kfxy+obq3JlHH1Btyg7gAAG8Z999//07em3YSL5kPoqyK5riDuNk51ROJ9l8jBM3cxawhOUH YY3l6SZXBL3/05PKeIjkr64b/h+/jPdL4jA9YXVeAU/V0+FxscWdF8RxBhufBRexbB/o8gE8 Jt/YaLznOrhYBCdB2xjbcRKPR7jiL2hUCrePf65PUr3/GA6GSQObB/DWb4iLvXFXOomL+y+e u0lBnG+H6cuZQmlyrmQW6/xm+4lqMQxXeX+LKsz3j/bfBx7usmOvPlBYDz3Es53ESdAWE9pg rqfq5uL0W2MZnQyrztN322lATNwBbFkBx0OUx5gcdsapudSebc2Gq+7hF9J3ahGI4rTVyc49 VMYm7gAamQt6gRiuj9KSxC/kcS3h5pZm2km7tBiGM79NmQt6P5KIjVuweSF9Kx3JxXyduiJ5 QybuAFTA28gbqOslsiuaWiK5ONNWnsFJrbx5QTxmsIIYJI4K+BM18QuTe+RTdIWGzuZzG4Zf xdtTixkn7c9Jck8N0fpAufw7qk9BDKiAt6uDG8NbL/IidXMS5FOXM21SEKuG4eKJYznC1evg MYlnm6Dz2E42xPDL6RuyC4srQ6zzzF42pF03DARN0PtMa95P37jhOs/U4jXH+e1X7ULWKA0C mM+F69gxXNzIkzjfSNYwjutjqxqPOZqM2JpalClfwLi4UlO9Sl4whiUxCGC2zOni0K08dKd2 UkniYgYnO5O4TebeWimJjdKCCzII6zAWGc/leqeH35lsvq08wvMLn4oTdU1tJ4dqbM3WPQxX SByDsA5WH9djeGpUF1P5mmxUYjifibp4LdPsNcotGWyUFlyBJugjpW++/dTKEEE/8fMl8mx2 JpN2VXqXn73kSaM0CGD2FcNTg7biUV1TCR1/KYNbSuRiBlfm9Kj0Lie9yI19yWIYBDA7rYnf 6dBNCuL8SyE9JG6xfi1OWD07S9f71bAkhnPQB3zyeJ6qes1z+VoSJ1NdTo2sTsrlJMXjvuQw Nw3IQ8z/9g3rHoYTMAr6il4IXQtILPArWl2v6emdt3ucysDhEkcTtPp4spM42WDB9M1bs4vT gNQuZ7rfkoIYOBYBfN30bUzWZLqPfFi1RuwWYyt0sa4tjttK7hvf8e/uQwzfb2IYDkcTNE0Z bDHjZavhOFmfmlqreIVxyNqlw/0Wnpz9A/hw4hiEBZ9O3+KKxVPfmq2V46Dt7rffj9b3EEL3 +wax6qoSgApYBfzpsri4v1Iiq6GXTfGpybYekjsaq5VP1+WZhA0TRx8wL8qnBHkzQa0t8Wz6 Fld5Sovp+23413VfYxjPXgEFfIAAZrFSeHa4VnH/1MbUrCByOh7PFaoDux7uNiTx7f7zb/0l ngABzOp1cDIXZlIQP3uBU2O41qfxulopHE/3ES+BnCyHHI+aDrf71DSZgADmKilejOT2Ylop nJTFobocclwQTyUxsDaDsNiLeLni+nCtZ3Odet1cuX7JWC1YL3FUwOyrDm5JzcZW7tle5Gt2 J5fnrP5tmh56iLvuS9M0rE0As9MwjldXDNmg63pOP9tGPdWLfNZszheHiJN4CGNN07A2TdCc 0MvBWWz0vsIzll+YlDdNF3uU4Zo0QcNkjtY3Zgdg5xdEndvUyolx03TXfcVFsKZpeJMA5uQZ /FRUv3ll1DliuNI0PV5G7PolEMAwE66VXuRK6BavjKoM4zrZeK60Dh79zqtVuX5JEoMAhqej Og7mpPZtD9fKNF4HTeKx3/cvjB+bpiUxvMBqSFBL5Tx6G2fcPJNkvaaH/++3cbjWsPjSmL4G bYEKGJbM48aZNesTXB86iStXEv8s+fA713ScvuOXgACG1uhtvxhpdgB2Ui5PXXy885CeTOL+ +6d1+nHVB0kMAhgWSOL68K4pLRNZ5zt3vhjUVBLHw7XyJB7oKubi9AHD8jk9tVEP3UN3JxdX gwghdPfbz9fDnB6luabNO40KGNgynuulcyhNmbnPkM4XYkquJC4OnDZ8GgEMrJu+U4k7G8nv rDmxlyQeLl5KLiZ+XPtBEiOAgdWTOL/4eGrPVEEc2hqrt10MKk7iv8bq34uJ/9Z++E3i8Hgh kyTmlPQBw+6CebbqDW3dyTtc1ml6+PTvdvcVwk9vcbwyhN8NVMDAlnlc/G77mhPFYN6kO7n1 QibpiwAGdpjNb645MdWdHKoTai470ebMhUzDKkzjP23RnIgmaDhVEjeu7xRXwGGhxuqvrntn +eTihUx/VzGF8DOCevxu/+3V59Bup1nBfpHlkeGClm18/u77N5M4/dOOxkU/ZHP3JYY5dOJo ggaemOl66gbFqnq2EbuxMk7m6PiplfvvYfj0+M/ryLFoggbp24+V64er6qFWHm6cbIzRnlfA cR7HFXCcwSpj9k8TNLBk6L4c5MUALi5r2LLE4RjGkpjdJo4KGFiskh6jd6qurSR08SLmewhD zuZN0HVj7iqL2a21+oC7xz+wLvt7W2oPsKsMDm0XR71wEfNrhq7ivMNYnzGb+0QF3HVd3/fD /8vuAXYexvWIrTRWJwXxInmcVMCKY7a1Sh9w3Di+Ru4WM1gfMJzMItHb2Hmsz5iXY25HFfCY l14hYHPDCOrZaaX1GfN5ZxuENQa/UhiOrlj7FuflqAfwc0e4R/NiZv3EIlnhu98A1kELfKCi nc3gqUWF81WHp44fSn3G6mN2XQGPHxA2CWPxD1fL4KmNOGLjPuA8g/M7Try9FMZwieFr/e5F Q5HeP9paE3GsN/ZqKtcNwoKzSi4gvt1DewUcB/CzFXDbe52a+IoOMxFHnppL7QGupiV9Q9Ty PA7CKqx4OHHHpzJ4ai5MkcxmFfBBP48AO6x9i569PCnO1Kdq3DfelOSxCnjrChjgNUPK5pNZ vnCoxsksk17h5Agt01BX4jZpr57qqP7AhwP2QAADpClbbKB+dkGIeiR33VcI927oXHscsJ30 XotkAQywZR0clpsguiWDixtJOrZfjlwox++3nyN3XyHc47I4Sf2kSpbHp/GfpwAgr3SnStKH EJ0K17Yf8ZOm/Xe438L9NiwXEW73v3+PPz0ZQVa80BkBDLCiccnCykb85bPpWwzRZGdcicYb U/unbhnH/BjGP//iML7du+4rH8s9NeUI+6cJGrhKYLe0YA8B+dV192wN49u9C2FoOf6pTou1 crG9unLLZJKQh0cz/LDR7T72HMf9x8UM1litAgZYOErjGreyke+vlMj5YXP32088D9ci12vo uiFYx4D86rr+ux+K3ngjTeH7bSiRx/+HJuu/hussfcflj4cfp0oWwAAv+u77cTnhcU9xI693 G5ujZ6P9fgtfXRc3Fc/+S/J1yMhhoyXyh1veb+lMXvdwC/fb8H/ff8eN1WOTdfyxII9kv1EC GGDFzC5GbCVo69H+WuHeWKZP3WDM4DGJhz7i4f+fVujfwB8iOQwXO8W9yI9DuOWxAAZ4JVPj ajjfiL+sl8izpXPlATx15JaDN9bxYxIPGZxk57DzL4mnR3WN6R43U4tkAQywWGA/VbzWo70S 6vXKuyXCnw3msY16/BcH89gv/NORnJXIQxLfwl0v8ueZCxpgG19dN4yvbvxwEA/Jjv+vZPZ4 myFb40iO/QV2uCffKK4r9dpEYGdiLmiAY9fl4Zl+5WIRPE6XnVw0lUfsd9+H0A0bQ4KOeRyV y7c4ksPt55Knv+CJroxKquHxaK59EsAAVw/1qYbuOI+TxurB787bw7cem6l/DhR98zeGTZzZ RBM0AH+G9upiL3IevmmTdUgnDyk2ep8gmDVBA7C8/vuvsfp+S3uRx2I3brKeKpFvyWReUYk8 XkkVrtpqLYAB+DO2WicdyWOr9d9lx4VkvaW172Me38MtLqzHb16zO1kTNABLvAk/DuyayJxC k/XMXXaZx5qgAdiLIR2/+9B/T+fx/faw8+cq5LQlO7l9Prwr/qHH7U4WwACsnsdjldx/92OO Di3SNdG3f3I6beXuiks0CmAASFN5DMgxPvO69yd577VBXrcQ7rfb7T4M5uri4V1TB9xVNgtg AHaRx1HOPgTzVB7/XAd1+ymOJ0rkv0I6bsTeQyQLYAD2XiiHMDVbyO3hquVwL7Rax1/+fr2H AdgCGIAD5PFUd3L8/5DHeZo+hHbisaqeGvC1RjC7DAmA40fAV7k7eTKJ2/I4uWM0fnv4+q08 VgEDcJIqeSoO80bsn+1soq50Jq8w2Yj9fjUsgAG4RDzHjdiTA7BDtRH7bxj2LfwuQiWAAeDd ijmplScr5lsIzywlKYAB4LlauRjMgzcn/RDAAPBcMHehC2/3Af/naQWAzxPAACCAAUAAAwAC GAAEMAAggAFAAAMAAhgABDAAIIABQAADgAAGAAQwAAhgAEAAA4AABgAEMAAIYABgrQDufiU7 85stsgcABHDouq7/NYblsDPOzqX2XFb+EceZOlkn60yd7NUr4GIkhxDG7FxqDwAI4B9DRgIA df/WLnw/7FLF8aXatbysTtaZOlkV8H7TFwCuWwFvlb4iH4DrVsB5+i4+9kp5DcAJ3JYNs6Tp fzx4nppL7QEAAQwANDEVJQAIYAAQwADASv6d4BzaR36d4EwvMk4tPotzv77j2cXncuKXNT7Z s76y74xFPcHJnv4NOTmRd17WMwRwKF0EPK7ccJoMLq4NlZzjOc46P9Ozvr75a3fulzU/2VO+ ssm787n/Wosne4U35EVe1nM2QZ9v5YbKh6yTrVfR8ot74pU5Lr4MyclONvlQde6XtfKXe6aT zRfoe+dl/e9Mf7onfnu6ztVilb/h872+l7oI8FKvbLjYpAXFCuF8L+vir+l/Z3perFR47j/v E7++l32zPusrO9ZDF3lBi6WhN+RZZ+gDNpfINSsn6Xv0kz3xWZ94KOjsyZ71fNd4KV2GBNLX yULTL/CybRv/neNJyT+RnX7lhuusV3Hi1/e1xUtOc7JnfWVbzutML+tF/mD7X2PR//7LejvN hVlJY8jJcug6VxYWz/Ssr+/FLxi9wit7wcu7T/+GvOB1wBZjAIAN6AMGAAEMAAIYABDAACCA AQABDAACGAAQwAAggAEAAQwAAhgABDAAsJ5/U99IlrNoX8lk6miVhTLajzOrZRmK+uIVjQvU vPyYlzoOACcM4CSQ4hUQ67d5Kn6G7deOU//Q8NRtkodRTMfkXi8/5uRnLXjuABzLJ5qgW3Jx kZ/yTu07LqScf+udaIyPWflZKmAAAVwLg67rnk3TjxV2LT/ltUfSXty/8PwAcE3/2uMzqQjj Mq492PJ7FcvBzdU/N1TK5RC1M8dFcOUzjQoYQABPhlAeDy39l7PDnZJu1wOVj/ljnhqnVk9W fcAAAviJEvCpUvJwAfPaQxWfALT7rzGB2mvT+Jb9r9DQBpvvX6Qgrh9kbCt+djBz+zPw5s8C 4JRuU03HeW3Xcv3uVI/mC9cBP5tSLY+5/Rrf4sVIzz4bLR9u9AEDCOBlLFLeLVgjKjcB2KH/ AdjzOoqApIL+AAAAAElFTkSuQmCC --uZ3hkaAS1mZxFaxD-- From buytenh@wantstofly.org Wed Dec 1 13:59:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Dec 2004 13:59:50 -0800 (PST) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB1Lxirr002754 for ; Wed, 1 Dec 2004 13:59:45 -0800 Received: by xi.wantstofly.org (Postfix, from userid 500) id 7BA6F2B101; Wed, 1 Dec 2004 22:59:23 +0100 (MET) Date: Wed, 1 Dec 2004 22:59:23 +0100 From: Lennert Buytenhek To: Robert Olsson Cc: netdev@oss.sgi.com Subject: Re: [PATCH,pktgen] account for preamble and inter-packet gap Message-ID: <20041201215923.GH14470@xi.wantstofly.org> References: <20041128213251.GA9330@xi.wantstofly.org> <16811.19277.594137.939120@robur.slu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16811.19277.594137.939120@robur.slu.se> User-Agent: Mutt/1.4.1i X-archive-position: 12375 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev On Mon, Nov 29, 2004 at 05:16:13PM +0100, Robert Olsson wrote: > I've heard some boxes that didn't do the ipg correctly. Don't know what NIC > this was. We can only estimate stats at the point where we are delivering > packets. Other devices has "true" L2 stats. Just found out the other day that via-rhine appears to do this. > OK. Adding FCS yes kinda compromise and maybe was wrong in this aspect. Let's remove it then? > The only solution I can think of is of having a selectable option in > the config for output stats. To support different L2 layers and with > warning if we are "predicting" L2 statistics. Feel free to extend your > patch. At that point it might be easier to just do it in userspace, no? --L From sjackman@gmail.com Wed Dec 1 14:03:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Dec 2004 14:03:48 -0800 (PST) Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.249]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB1M3fSQ003184 for ; Wed, 1 Dec 2004 14:03:42 -0800 Received: by mproxy.gmail.com with SMTP id w41so88283cwb for ; Wed, 01 Dec 2004 14:03:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=SdwSV4xL+mxR4tLQ/vd+ZennOM9ZCci6fHRQLD19YMy5YRmYsoPTXwFxMUPmx/1CHUh6LVIUJa766uCakASbKSy1Mowr7dtF5GwaWDRgn69iGZX/sxowkM1Cwo5+7wKsGrfa0IWh0aVFhGeKsPma6K4e/su00/CSvlw4eqleM5M= Received: by 10.11.116.64 with SMTP id o64mr326004cwc; Wed, 01 Dec 2004 14:03:17 -0800 (PST) Received: by 10.11.99.50 with HTTP; Wed, 1 Dec 2004 14:03:17 -0800 (PST) Message-ID: <7f45d939041201140329d0273f@mail.gmail.com> Date: Wed, 1 Dec 2004 14:03:17 -0800 From: Shaun Jackman Reply-To: Shaun Jackman To: netdev@oss.sgi.com, Andrew Morton Subject: Re: Multicast filtering for tun.c [PATCH] In-Reply-To: <20041127011006.03232bb6.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <7f45d9390411251715138b35d0@mail.gmail.com> <20041127011006.03232bb6.akpm@osdl.org> X-archive-position: 12376 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sjackman@gmail.com Precedence: bulk X-list: netdev This patch adds multicast filtering to the TUN network driver, for packets being sent from the network device to the character device. It applies against the 2.6.8.1 kernel tree. Cheers, Shaun On Sat, 27 Nov 2004 01:10:06 -0800, Andrew Morton wrote: > Shaun Jackman wrote: > > > > This patch adds multicast filtering to the TUN network driver, > > You should cc netdev@oss.sgi.com on networking stuff. > > You may not get any feedback on this work. Persist. If you get nowhere, > ping me and I'll help push things along. > > > This is my first attempt at sending a patch using gmail. > > Send the patch to yourself first, check that the result applies OK. 2004-11-25 Shaun Jackman * drivers/net/tun.c: Add multicast filtering for packets travelling from the network device to the character device. * include/linux/if_tun.h (tun_struct): Add interface flags, a hardware device addres, and a multicast filter. diff -ur linux-2.6.8.1.orig/drivers/net/tun.c linux-2.6.8.1/drivers/net/tun.c --- linux-2.6.8.1.orig/drivers/net/tun.c 2004-08-14 03:55:23.000000000 -0700 +++ linux-2.6.8.1/drivers/net/tun.c 2004-11-25 17:00:22.000000000 -0800 @@ -41,6 +41,7 @@ #include #include #include +#include #include #include @@ -104,11 +105,42 @@ return 0; } -static void tun_net_mclist(struct net_device *dev) +/** Add the specified Ethernet address to this multicast filter. */ +static void +add_multi(u32* filter, const u8* addr) { - /* Nothing to do for multicast filters. - * We always accept all frames. */ - return; + int bit_nr = ether_crc(ETH_ALEN, addr) >> 26; + filter[bit_nr >> 5] |= 1 << (bit_nr & 31); +} + +/** Remove the specified Ethernet addres from this multicast filter. */ +static void +del_multi(u32* filter, const u8* addr) +{ + int bit_nr = ether_crc(ETH_ALEN, addr) >> 26; + filter[bit_nr >> 5] &= ~(1 << (bit_nr & 31)); +} + +/** Update the list of multicast groups to which the network device belongs. + * This list is used to filter packets being sent from the character device to + * the network device. */ +static void +tun_net_mclist(struct net_device *dev) +{ + struct tun_struct *tun = netdev_priv(dev); + const struct dev_mc_list *mclist; + int i; + DBG(KERN_DEBUG "%s: tun_net_mclist: mc_count %d\n", + dev->name, dev->mc_count); + memset(tun->chr_filter, 0, sizeof tun->chr_filter); + for (i = 0, mclist = dev->mc_list; i < dev->mc_count && mclist != NULL; + i++, mclist = mclist->next) { + add_multi(tun->net_filter, mclist->dmi_addr); + DBG(KERN_DEBUG "%s: tun_net_mclist: %x:%x:%x:%x:%x:%x\n", + dev->name, + mclist->dmi_addr[0], mclist->dmi_addr[1], mclist->dmi_addr[2], + mclist->dmi_addr[3], mclist->dmi_addr[4], mclist->dmi_addr[5]); + } } static struct net_device_stats *tun_net_stats(struct net_device *dev) @@ -301,6 +333,10 @@ add_wait_queue(&tun->read_wait, &wait); while (len) { + const u8 ones[ ETH_ALEN] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; + u8 addr[ ETH_ALEN]; + int bit_nr; + current->state = TASK_INTERRUPTIBLE; /* Read frames from the queue */ @@ -320,10 +356,37 @@ } netif_start_queue(tun->dev); - ret = tun_put_user(tun, skb, (struct iovec *) iv, len); - - kfree_skb(skb); - break; + /** Decide whether to accept this packet. This code is designed to + * behave identically to an Ethernet interface. Accept the packet if + * - we are promiscuous. + * - the packet is addressed to us. + * - the packet is broadcast. + * - the packet is multicast and + * - we are multicast promiscous. + * - we belong to the multicast group. + */ + memcpy(addr, skb->data, min(sizeof addr, skb->len)); + bit_nr = ether_crc(sizeof addr, addr) >> 26; + if ((tun->if_flags & IFF_PROMISC) || + memcmp(addr, tun->dev_addr, sizeof addr) == 0 || + memcmp(addr, ones, sizeof addr) == 0 || + (((addr[0] == 1 && addr[1] == 0 && addr[2] == 0x5e) || + (addr[0] == 0x33 && addr[1] == 0x33)) && + ((tun->if_flags & IFF_ALLMULTI) || + (tun->chr_filter[bit_nr >> 5] & (1 << (bit_nr & 31)))))) { + DBG(KERN_DEBUG "%s: tun_chr_readv: accepted: %x:%x:%x:%x:%x:%x\n", + tun->dev->name, addr[0], addr[1], addr[2], + addr[3], addr[4], addr[5]); + ret = tun_put_user(tun, skb, (struct iovec *) iv, len); + kfree_skb(skb); + break; + } else { + DBG(KERN_DEBUG "%s: tun_chr_readv: rejected: %x:%x:%x:%x:%x:%x\n", + tun->dev->name, addr[0], addr[1], addr[2], + addr[3], addr[4], addr[5]); + kfree_skb(skb); + continue; + } } current->state = TASK_RUNNING; @@ -417,6 +480,12 @@ tun = netdev_priv(dev); tun->dev = dev; tun->flags = flags; + /* Be promiscuous by default to maintain previous behaviour. */ + tun->if_flags = IFF_PROMISC; + /* Generate random Ethernet address. */ + *(u16 *)tun->dev_addr = htons(0x00FF); + get_random_bytes(tun->dev_addr + sizeof(u16), 4); + memset(tun->chr_filter, 0, sizeof tun->chr_filter); tun_net_init(dev); @@ -457,13 +526,16 @@ unsigned int cmd, unsigned long arg) { struct tun_struct *tun = file->private_data; + void __user* argp = (void __user*)arg; + struct ifreq ifr; + + if (cmd == TUNSETIFF || _IOC_TYPE(cmd) == 0x89) + if (copy_from_user(&ifr, argp, sizeof ifr)) + return -EFAULT; if (cmd == TUNSETIFF && !tun) { - struct ifreq ifr; int err; - if (copy_from_user(&ifr, (void __user *)arg, sizeof(ifr))) - return -EFAULT; ifr.ifr_name[IFNAMSIZ-1] = '\0'; rtnl_lock(); @@ -473,7 +545,7 @@ if (err) return err; - if (copy_to_user((void __user *)arg, &ifr, sizeof(ifr))) + if (copy_to_user(argp, &ifr, sizeof(ifr))) return -EFAULT; return 0; } @@ -519,6 +591,61 @@ break; #endif + case SIOCGIFFLAGS: + ifr.ifr_flags = tun->if_flags; + if (copy_to_user( argp, &ifr, sizeof ifr)) + return -EFAULT; + return 0; + + case SIOCSIFFLAGS: + /** Set the character device's interface flags. Currently only + * IFF_PROMISC and IFF_ALLMULTI are used. */ + tun->if_flags = ifr.ifr_flags; + DBG(KERN_INFO "%s: interface flags 0x%lx\n", + tun->dev->name, tun->if_flags); + return 0; + + case SIOCGIFHWADDR: + memcpy(ifr.ifr_hwaddr.sa_data, tun->dev_addr, + min(sizeof ifr.ifr_hwaddr.sa_data, sizeof tun->dev_addr)); + if (copy_to_user( argp, &ifr, sizeof ifr)) + return -EFAULT; + return 0; + + case SIOCSIFHWADDR: + /** Set the character device's hardware address. This is used when + * filtering packets being sent from the network device to the character + * device. */ + memcpy(tun->dev_addr, ifr.ifr_hwaddr.sa_data, + min(sizeof ifr.ifr_hwaddr.sa_data, sizeof tun->dev_addr)); + DBG(KERN_DEBUG "%s: set hardware address: %x:%x:%x:%x:%x:%x\n", + tun->dev->name, + tun->dev_addr[0], tun->dev_addr[1], tun->dev_addr[2], + tun->dev_addr[3], tun->dev_addr[4], tun->dev_addr[5]); + return 0; + + case SIOCADDMULTI: + /** Add the specified group to the character device's multicast filter + * list. */ + add_multi(tun->chr_filter, ifr.ifr_hwaddr.sa_data); + DBG(KERN_DEBUG "%s: add multi: %x:%x:%x:%x:%x:%x\n", + tun->dev->name, + (u8)ifr.ifr_hwaddr.sa_data[0], (u8)ifr.ifr_hwaddr.sa_data[1], + (u8)ifr.ifr_hwaddr.sa_data[2], (u8)ifr.ifr_hwaddr.sa_data[3], + (u8)ifr.ifr_hwaddr.sa_data[4], (u8)ifr.ifr_hwaddr.sa_data[5]); + return 0; + + case SIOCDELMULTI: + /** Remove the specified group from the character device's multicast + * filter list. */ + del_multi(tun->chr_filter, ifr.ifr_hwaddr.sa_data); + DBG(KERN_DEBUG "%s: del multi: %x:%x:%x:%x:%x:%x\n", + tun->dev->name, + (u8)ifr.ifr_hwaddr.sa_data[0], (u8)ifr.ifr_hwaddr.sa_data[1], + (u8)ifr.ifr_hwaddr.sa_data[2], (u8)ifr.ifr_hwaddr.sa_data[3], + (u8)ifr.ifr_hwaddr.sa_data[4], (u8)ifr.ifr_hwaddr.sa_data[5]); + return 0; + default: return -EINVAL; }; diff -ur linux-2.6.8.1.orig/include/linux/if_tun.h linux-2.6.8.1/include/linux/if_tun.h --- linux-2.6.8.1.orig/include/linux/if_tun.h 2004-08-14 03:55:09.000000000 -0700 +++ linux-2.6.8.1/include/linux/if_tun.h 2004-11-25 16:47:31.000000000 -0800 @@ -45,6 +45,11 @@ struct fasync_struct *fasync; + unsigned long if_flags; + u8 dev_addr[ETH_ALEN]; + u32 chr_filter[2]; + u32 net_filter[2]; + #ifdef TUN_DEBUG int debug; #endif From jketreno@linux.intel.com Wed Dec 1 17:35:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Dec 2004 17:35:45 -0800 (PST) Received: from orsfmr003.jf.intel.com (fmr18.intel.com [134.134.136.17]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB21ZQbP012623 for ; Wed, 1 Dec 2004 17:35:30 -0800 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id iB21Z0xK001499 for ; Thu, 2 Dec 2004 01:35:00 GMT Received: from linux.intel.com (vpnfm001-139-dhcp-client.fm.intel.com [10.19.13.139]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with ESMTP id iB21Q9uc018759 for ; Thu, 2 Dec 2004 01:26:09 GMT Message-ID: <41AE7143.80505@linux.intel.com> Date: Wed, 01 Dec 2004 19:34:59 -0600 From: James Ketrenos User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netdev Subject: Steps for netdev-2.6 inclusion? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 12377 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jketreno@linux.intel.com Precedence: bulk X-list: netdev Ok, its been a long time coming, but it appears the ipw* wireless drivers are to the point where being more proactive at getting them into the kernel is appropriate (at least based on the frequency of emails I'm getting of 'why isn't this in mainline?') So, what would be the set of steps required to get a version in the queue for inclusion? The drivers we have are the ipw2100 (supporting the Intel PRO/Wireless 2100 Network Connection adapter) and ipw2200 (supporting the Intel PRO/Wireless 2200BG and 2915ABG Network Connection adapters). There is also a shared generic ieee 802.11 stack (ieee80211*.ko) supporting 802.11b, g, and a for BSS and IBSS modes. The ipw2100 recently was stamped 1.0.0, which means we've put it through a validation and stabalization phase. As we want to try and ensure end users don't have to spend all night fighting with their wireless connection just because they've updated the kernel, we've adopted the following version numbering scheme for the ipw* drivers in the form of of x.y.z, where: .z increases from snapshot to snapshot (pushed out as tarballs on SourceForge) .y increases (and sets .z to 0) when a snapshot has gone through a regression validation cycle. .x increases if there are significant functionality changes to the driver. The idea is to then only have x.y.0 (stable/tested) versions go out for wider distribution (kernel inclusion). For those that are curious, the tip of development for the ipw2100, ipw2200, and ieee80211 stack is available at bk://ipw.bkbits.net/ipw-2.6. Given what I described above, would it be most appropriate to create a ipw-2.6-stable bk tree with the parent as netdev-2.6 that we put the stable versions of the ipw* drivers into, and then request that be pulled? The ipw-2.6 tree could then continue to represent the development tip. I've searched around for some BKMs on this, but haven't found a whole lot. The ipw2100 1.0.0 snapshot (and newer versions) can be found at http://ipw2100.sf.net/#downloads. The latest ipw2200 snapshot (0.15) is available at http://ipw2200.sf.net/#downloads. Also, we have a Bugzilla database setup for the above drivers at http://bughost.org for those that are curious about current remaining issues, etc. Thanks, James From horms@koto.vergenet.net Wed Dec 1 20:31:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Dec 2004 20:31:54 -0800 (PST) Received: from koto.vergenet.net (koto.vergenet.net [210.128.90.7]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iB24VjpX020259 for ; Wed, 1 Dec 2004 20:31:45 -0800 Received: (qmail 26081 invoked by uid 7100); 2 Dec 2004 04:15:29 -0000 Date: Thu, 2 Dec 2004 13:07:20 +0900 From: Horms To: Wensong Zhang Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] [IPVS] add a sysctl variable to expire quiescent template Message-ID: <20041202040717.GF32190@verge.net.au> Mail-Followup-To: Wensong Zhang , "David S. Miller" , netdev@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Cluestick: seven User-Agent: Mutt/1.5.6+20040907i X-archive-position: 12378 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: horms@verge.net.au Precedence: bulk X-list: netdev On Thu, Dec 02, 2004 at 12:48:26AM +0800, Wensong Zhang wrote: > > > Hi Dave, > > Here is the patch from Horms to add a sysctl > variable to expire quiescent templat. Please check and apply them to > kernel 2.4 and 2.6 respectively. > > Thanks, > > Wensong I can do this too, just in case you need it. Signed-off-by: Horms > # This is a BitKeeper generated diff -Nru style patch. > # > # ChangeSet > # 2004/12/02 00:02:48+08:00 wensong@linux-vs.org > # [IPVS] add a sysctl variable to expire quiescent template > # > # The patch is from Horms > # > # net/ipv4/ipvs/ip_vs_ctl.c > # 2004/12/02 00:02:38+08:00 wensong@linux-vs.org +4 -0 > # set sysctl_ip_vs_expire_quiescent_template > # > # net/ipv4/ipvs/ip_vs_conn.c > # 2004/12/02 00:02:37+08:00 wensong@linux-vs.org +3 -1 > # don't use quiescent template if the expire_quiescent_template is enabled > # > # include/net/ip_vs.h > # 2004/12/02 00:02:37+08:00 wensong@linux-vs.org +2 -0 > # add the sysctl_ip_vs_expire_quiescent_template > # > diff -Nru a/include/net/ip_vs.h b/include/net/ip_vs.h > --- a/include/net/ip_vs.h 2004-12-02 00:16:36 +08:00 > +++ b/include/net/ip_vs.h 2004-12-02 00:16:36 +08:00 > @@ -317,6 +317,7 @@ > NET_IPV4_VS_EXPIRE_NODEST_CONN=23, > NET_IPV4_VS_SYNC_THRESHOLD=24, > NET_IPV4_VS_NAT_ICMP_SEND=25, > + NET_IPV4_VS_EXPIRE_QUIESCENT_TEMPLATE=26, > NET_IPV4_VS_LAST > }; > > @@ -700,6 +701,7 @@ > */ > extern int sysctl_ip_vs_cache_bypass; > extern int sysctl_ip_vs_expire_nodest_conn; > +extern int sysctl_ip_vs_expire_quiescent_template; > extern int sysctl_ip_vs_sync_threshold; > extern int sysctl_ip_vs_nat_icmp_send; > extern struct ip_vs_stats ip_vs_stats; > diff -Nru a/net/ipv4/ipvs/ip_vs_conn.c b/net/ipv4/ipvs/ip_vs_conn.c > --- a/net/ipv4/ipvs/ip_vs_conn.c 2004-12-02 00:16:36 +08:00 > +++ b/net/ipv4/ipvs/ip_vs_conn.c 2004-12-02 00:16:36 +08:00 > @@ -1131,7 +1131,9 @@ > * Checking the dest server status. > */ > if ((dest == NULL) || > - !(dest->flags & IP_VS_DEST_F_AVAILABLE)) { > + !(dest->flags & IP_VS_DEST_F_AVAILABLE) || > + (sysctl_ip_vs_expire_quiescent_template && > + (atomic_read(&dest->weight) == 0))) { > IP_VS_DBG(9, "check_template: dest not available for " > "protocol %s s:%u.%u.%u.%u:%d v:%u.%u.%u.%u:%d " > "-> d:%u.%u.%u.%u:%d\n", > diff -Nru a/net/ipv4/ipvs/ip_vs_ctl.c b/net/ipv4/ipvs/ip_vs_ctl.c > --- a/net/ipv4/ipvs/ip_vs_ctl.c 2004-12-02 00:16:36 +08:00 > +++ b/net/ipv4/ipvs/ip_vs_ctl.c 2004-12-02 00:16:36 +08:00 > @@ -74,6 +74,7 @@ > static int sysctl_ip_vs_am_droprate = 10; > int sysctl_ip_vs_cache_bypass = 0; > int sysctl_ip_vs_expire_nodest_conn = 0; > +int sysctl_ip_vs_expire_quiescent_template = 0; > int sysctl_ip_vs_sync_threshold = 3; > int sysctl_ip_vs_nat_icmp_send = 0; > > @@ -1439,6 +1440,9 @@ > &proc_dointvec}, > {NET_IPV4_VS_NAT_ICMP_SEND, "nat_icmp_send", > &sysctl_ip_vs_nat_icmp_send, sizeof(int), 0644, NULL, > + &proc_dointvec}, > + {NET_IPV4_VS_EXPIRE_QUIESCENT_TEMPLATE, "expire_quiescent_template", > + &sysctl_ip_vs_expire_quiescent_template, sizeof(int), 0644, NULL, > &proc_dointvec}, > {0}}, > {{NET_IPV4_VS, "vs", NULL, 0, 0555, ipv4_vs_table.vs_vars}, > # This is a BitKeeper generated diff -Nru style patch. > # > # ChangeSet > # 2004/12/02 00:42:15+08:00 wensong@linux-vs.org > # [IPVS] add a sysctl variable to expire quiescent template > # > # The patch is from Horms > # > # net/ipv4/ipvs/ip_vs_ctl.c > # 2004/12/02 00:41:56+08:00 wensong@linux-vs.org +20 -11 > # set the sysctl_ip_vs_expire_quiescent_template > # > # net/ipv4/ipvs/ip_vs_conn.c > # 2004/12/02 00:41:56+08:00 wensong@linux-vs.org +3 -1 > # don't use quiescent template if the expire_quiescent_template is enabled > # > # include/net/ip_vs.h > # 2004/12/02 00:41:56+08:00 wensong@linux-vs.org +2 -0 > # add the sysctl_ip_vs_expire_quiescent_template prototype > # > diff -Nru a/include/net/ip_vs.h b/include/net/ip_vs.h > --- a/include/net/ip_vs.h 2004-12-02 00:43:14 +08:00 > +++ b/include/net/ip_vs.h 2004-12-02 00:43:14 +08:00 > @@ -358,6 +358,7 @@ > NET_IPV4_VS_EXPIRE_NODEST_CONN=23, > NET_IPV4_VS_SYNC_THRESHOLD=24, > NET_IPV4_VS_NAT_ICMP_SEND=25, > + NET_IPV4_VS_EXPIRE_QUIESCENT_TEMPLATE=26, > NET_IPV4_VS_LAST > }; > > @@ -879,6 +880,7 @@ > */ > extern int sysctl_ip_vs_cache_bypass; > extern int sysctl_ip_vs_expire_nodest_conn; > +extern int sysctl_ip_vs_expire_quiescent_template; > extern int sysctl_ip_vs_sync_threshold[2]; > extern int sysctl_ip_vs_nat_icmp_send; > extern struct ip_vs_stats ip_vs_stats; > diff -Nru a/net/ipv4/ipvs/ip_vs_conn.c b/net/ipv4/ipvs/ip_vs_conn.c > --- a/net/ipv4/ipvs/ip_vs_conn.c 2004-12-02 00:43:14 +08:00 > +++ b/net/ipv4/ipvs/ip_vs_conn.c 2004-12-02 00:43:14 +08:00 > @@ -453,7 +453,9 @@ > * Checking the dest server status. > */ > if ((dest == NULL) || > - !(dest->flags & IP_VS_DEST_F_AVAILABLE)) { > + !(dest->flags & IP_VS_DEST_F_AVAILABLE) || > + (sysctl_ip_vs_expire_quiescent_template && > + (atomic_read(&dest->weight) == 0))) { > IP_VS_DBG(9, "check_template: dest not available for " > "protocol %s s:%u.%u.%u.%u:%d v:%u.%u.%u.%u:%d " > "-> d:%u.%u.%u.%u:%d\n", > diff -Nru a/net/ipv4/ipvs/ip_vs_ctl.c b/net/ipv4/ipvs/ip_vs_ctl.c > --- a/net/ipv4/ipvs/ip_vs_ctl.c 2004-12-02 00:43:14 +08:00 > +++ b/net/ipv4/ipvs/ip_vs_ctl.c 2004-12-02 00:43:14 +08:00 > @@ -75,6 +75,7 @@ > static int sysctl_ip_vs_am_droprate = 10; > int sysctl_ip_vs_cache_bypass = 0; > int sysctl_ip_vs_expire_nodest_conn = 0; > +int sysctl_ip_vs_expire_quiescent_template = 0; > int sysctl_ip_vs_sync_threshold[2] = { 3, 50 }; > int sysctl_ip_vs_nat_icmp_send = 0; > > @@ -1447,9 +1448,9 @@ > { > .ctl_name = NET_IPV4_VS_TO_ES, > .procname = "timeout_established", > - .data = &vs_timeout_table_dos.timeout[IP_VS_S_ESTABLISHED], > + .data = &vs_timeout_table_dos.timeout[IP_VS_S_ESTABLISHED], > .maxlen = sizeof(int), > - .mode = 0644, > + .mode = 0644, > .proc_handler = &proc_dointvec_jiffies, > }, > { > @@ -1457,7 +1458,7 @@ > .procname = "timeout_synsent", > .data = &vs_timeout_table_dos.timeout[IP_VS_S_SYN_SENT], > .maxlen = sizeof(int), > - .mode = 0644, > + .mode = 0644, > .proc_handler = &proc_dointvec_jiffies, > }, > { > @@ -1465,7 +1466,7 @@ > .procname = "timeout_synrecv", > .data = &vs_timeout_table_dos.timeout[IP_VS_S_SYN_RECV], > .maxlen = sizeof(int), > - .mode = 0644, > + .mode = 0644, > .proc_handler = &proc_dointvec_jiffies, > }, > { > @@ -1473,7 +1474,7 @@ > .procname = "timeout_finwait", > .data = &vs_timeout_table_dos.timeout[IP_VS_S_FIN_WAIT], > .maxlen = sizeof(int), > - .mode = 0644, > + .mode = 0644, > .proc_handler = &proc_dointvec_jiffies, > }, > { > @@ -1489,7 +1490,7 @@ > .procname = "timeout_close", > .data = &vs_timeout_table_dos.timeout[IP_VS_S_CLOSE], > .maxlen = sizeof(int), > - .mode = 0644, > + .mode = 0644, > .proc_handler = &proc_dointvec_jiffies, > }, > { > @@ -1497,7 +1498,7 @@ > .procname = "timeout_closewait", > .data = &vs_timeout_table_dos.timeout[IP_VS_S_CLOSE_WAIT], > .maxlen = sizeof(int), > - .mode = 0644, > + .mode = 0644, > .proc_handler = &proc_dointvec_jiffies, > }, > { > @@ -1505,7 +1506,7 @@ > .procname = "timeout_lastack", > .data = &vs_timeout_table_dos.timeout[IP_VS_S_LAST_ACK], > .maxlen = sizeof(int), > - .mode = 0644, > + .mode = 0644, > .proc_handler = &proc_dointvec_jiffies, > }, > { > @@ -1513,7 +1514,7 @@ > .procname = "timeout_listen", > .data = &vs_timeout_table_dos.timeout[IP_VS_S_LISTEN], > .maxlen = sizeof(int), > - .mode = 0644, > + .mode = 0644, > .proc_handler = &proc_dointvec_jiffies, > }, > { > @@ -1521,7 +1522,7 @@ > .procname = "timeout_synack", > .data = &vs_timeout_table_dos.timeout[IP_VS_S_SYNACK], > .maxlen = sizeof(int), > - .mode = 0644, > + .mode = 0644, > .proc_handler = &proc_dointvec_jiffies, > }, > { > @@ -1529,7 +1530,7 @@ > .procname = "timeout_udp", > .data = &vs_timeout_table_dos.timeout[IP_VS_S_UDP], > .maxlen = sizeof(int), > - .mode = 0644, > + .mode = 0644, > .proc_handler = &proc_dointvec_jiffies, > }, > { > @@ -1553,6 +1554,14 @@ > .ctl_name = NET_IPV4_VS_EXPIRE_NODEST_CONN, > .procname = "expire_nodest_conn", > .data = &sysctl_ip_vs_expire_nodest_conn, > + .maxlen = sizeof(int), > + .mode = 0644, > + .proc_handler = &proc_dointvec, > + }, > + { > + .ctl_name = NET_IPV4_VS_EXPIRE_QUIESCENT_TEMPLATE, > + .procname = "expire_quiescent_template", > + .data = &sysctl_ip_vs_expire_quiescent_template, > .maxlen = sizeof(int), > .mode = 0644, > .proc_handler = &proc_dointvec, -- Horms From sfeldma@pobox.com Wed Dec 1 22:11:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Dec 2004 22:11:23 -0800 (PST) Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB26BGK4022289 for ; Wed, 1 Dec 2004 22:11:17 -0800 Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id 2F5622FA235; Thu, 2 Dec 2004 01:10:55 -0500 (EST) Received: from [192.168.2.72] (adsl-68-127-20-190.dsl.pltn13.pacbell.net [68.127.20.190]) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id 585752F9F7E; Thu, 2 Dec 2004 01:10:45 -0500 (EST) Subject: Re: [E1000-devel] Transmission limit From: Scott Feldman Reply-To: sfeldma@pobox.com To: Lennert Buytenhek Cc: jamal , Robert Olsson , P@draigBrady.com, mellia@prezzemolo.polito.it, e1000-devel@lists.sourceforge.net, Jorge Manuel Finochietto , Giulio Galante , netdev@oss.sgi.com In-Reply-To: <20041201213550.GF14470@xi.wantstofly.org> References: <1101484740.24742.213.camel@mellia.lipar.polito.it> <41A76085.7000105@draigBrady.com> <1101499285.1079.45.camel@jzny.localdomain> <16811.8052.678955.795327@robur.slu.se> <1101821501.1043.43.camel@jzny.localdomain> <20041130134600.GA31515@xi.wantstofly.org> <1101824754.1044.126.camel@jzny.localdomain> <20041201001107.GE4203@xi.wantstofly.org> <1101863399.4663.54.camel@sfeldma-mobl.dsl-verizon.net> <20041201182943.GA14470@xi.wantstofly.org> <20041201213550.GF14470@xi.wantstofly.org> Content-Type: text/plain Message-Id: <1101967983.4782.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 01 Dec 2004 22:13:33 -0800 Content-Transfer-Encoding: 7bit X-archive-position: 12379 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sfeldma@pobox.com Precedence: bulk X-list: netdev On Wed, 2004-12-01 at 13:35, Lennert Buytenhek wrote: > Pretty graph attached. From ~220B packets or so it does wire speed, but > there's still an odd drop in performance around 256B packets (which is > also there without your patch.) From 350B packets or so, performance is > identical with or without your patch (wire speed.) Seems this is helping PCI nics but not PCI-X. I was using PCI 32/33. Can't explain the dip around 256B. > So. Do you have any other good plans perhaps? :) Idea#1 Is the write of TDT causing interference with DMA transactions? In addition to my patch, what happens if you bump the Tx tail every n packets, where n is like 16 or 32 or 64? if((i % 16) == 0) E1000_REG_WRITE(&adapter->hw, TDT, i); This might piss the NETDEV timer off if the send count isn't a multiple of n, so you might want to disable netdev->tx_timeout. Idea#2 The Ultimate: queue up 4096 packets and then write TDT once to send all 4096 in one shot. Well, maybe a few less that 4096 so we don't wrap the ring. How about pkt_size = 4000? Take my patch and change the timer call in e1000_xmit_frame from jiffies + 1 to jiffies + HZ This will schedule the cleanup of the skbs 1 second after the first queue, so we shouldn't be doing any cleanup while the 4000 packets are DMA'ed. Oh, and change the tail write to if((i % 4000) == 0) E1000_REG_WRITE(&adapter->hw, TDT, i); Of course you'll need to close/open the driver after each run. Idea#3 http://www.mail-archive.com/freebsd-net@freebsd.org/msg10826.html Set TXDMAC to 0 in e1000_configure_tx. > > Once or twice it went into a state where it started spitting out these > > kinds of messages and never recovered: > > > > Dec 1 19:13:18 phi kernel: NETDEV WATCHDOG: eth1: transmit timed out > > [...] > > Dec 1 19:13:31 phi kernel: NETDEV WATCHDOG: eth1: transmit timed out > > [...] > > Dec 1 19:13:43 phi kernel: NETDEV WATCHDOG: eth1: transmit timed out > > Didn't see this happen anymore. (ifconfig down and then up recovered it > both times I saw it happen.) Well, it's probably not a HW bug that's causing the reset; it's probably some bug with my patch. -scott From jgarzik@pobox.com Wed Dec 1 22:19:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Dec 2004 22:19:11 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB26J6O8022740 for ; Wed, 1 Dec 2004 22:19:06 -0800 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CZkId-00016k-W9; Thu, 02 Dec 2004 06:18:44 +0000 Message-ID: <41AEB3B8.2000406@pobox.com> Date: Thu, 02 Dec 2004 01:18:32 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Ketrenos CC: Netdev Subject: Re: Steps for netdev-2.6 inclusion? References: <41AE7143.80505@linux.intel.com> In-Reply-To: <41AE7143.80505@linux.intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12380 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 It's fairly easy, just email me and netdev the patch for inclusion, and it'll get reviewed. Once review issues are addressed, I'll merge it immediately, which causes it to be automatically propagated to Andrew Morton's -mm tree for testing. Once consensus agrees that we can push this + HostAP upstream, that's an easy 10-minute task. One potential showstopper is firmware crapola: I'm concerned about a situation where we have drivers in the kernel, but the firmware must be downloaded from SourceForge or somesuch. IOW, the kernel driver as-is is useless without a differently-licensed firmware. Comments? Jeff From akpm@osdl.org Wed Dec 1 23:34:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Dec 2004 23:34:55 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB27YpGI024362 for ; Wed, 1 Dec 2004 23:34:51 -0800 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id iB27YM912409; Wed, 1 Dec 2004 23:34:22 -0800 Date: Wed, 1 Dec 2004 23:34:00 -0800 From: Andrew Morton To: Shaun Jackman Cc: netdev@oss.sgi.com Subject: Re: Multicast filtering for tun.c [PATCH] Message-Id: <20041201233400.45078efe.akpm@osdl.org> In-Reply-To: <7f45d939041201140329d0273f@mail.gmail.com> References: <7f45d9390411251715138b35d0@mail.gmail.com> <20041127011006.03232bb6.akpm@osdl.org> <7f45d939041201140329d0273f@mail.gmail.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 12381 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Shaun Jackman wrote: > > This patch adds multicast filtering to the TUN network driver, for > packets being sent from the network device to the character device. It > applies against the 2.6.8.1 kernel tree. > > ... Minor points: > diff -ur linux-2.6.8.1.orig/drivers/net/tun.c linux-2.6.8.1/drivers/net/tun.c > --- linux-2.6.8.1.orig/drivers/net/tun.c 2004-08-14 03:55:23.000000000 -0700 > +++ linux-2.6.8.1/drivers/net/tun.c 2004-11-25 17:00:22.000000000 -0800 > @@ -41,6 +41,7 @@ > #include > #include > #include > +#include You're sure this shouldn't be using crc-ccitt? > +del_multi(u32* filter, const u8* addr) del_multi(u32 *filter, const u8 *addr) would be a more typical layout. > static struct net_device_stats *tun_net_stats(struct net_device *dev) > @@ -301,6 +333,10 @@ > > add_wait_queue(&tun->read_wait, &wait); > while (len) { > + const u8 ones[ ETH_ALEN] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; The space after the `[' is gratuitous. This array will be allocated onthe stack and populated by hand each time this function is called. It should be made static. > + u8 addr[ ETH_ALEN]; extraneous space. > + memcpy(addr, skb->data, min(sizeof addr, skb->len)); We normally put parentheses around the argument of the sizeof operator, for no particular reason ;) > + if (copy_from_user(&ifr, argp, sizeof ifr)) Ditto > + case SIOCGIFFLAGS: > + ifr.ifr_flags = tun->if_flags; > + if (copy_to_user( argp, &ifr, sizeof ifr)) extraneous space. > + if (copy_to_user( argp, &ifr, sizeof ifr)) ditto > + DBG(KERN_DEBUG "%s: add multi: %x:%x:%x:%x:%x:%x\n", > + tun->dev->name, > + (u8)ifr.ifr_hwaddr.sa_data[0], (u8)ifr.ifr_hwaddr.sa_data[1], > + (u8)ifr.ifr_hwaddr.sa_data[2], (u8)ifr.ifr_hwaddr.sa_data[3], > + (u8)ifr.ifr_hwaddr.sa_data[4], (u8)ifr.ifr_hwaddr.sa_data[5]); Why all the typecasts? > + case SIOCDELMULTI: > + /** Remove the specified group from the character device's multicast > + * filter list. */ > + del_multi(tun->chr_filter, ifr.ifr_hwaddr.sa_data); > + DBG(KERN_DEBUG "%s: del multi: %x:%x:%x:%x:%x:%x\n", > + tun->dev->name, > + (u8)ifr.ifr_hwaddr.sa_data[0], (u8)ifr.ifr_hwaddr.sa_data[1], > + (u8)ifr.ifr_hwaddr.sa_data[2], (u8)ifr.ifr_hwaddr.sa_data[3], > + (u8)ifr.ifr_hwaddr.sa_data[4], (u8)ifr.ifr_hwaddr.sa_data[5]); ditto. From cranium2003@yahoo.com Thu Dec 2 01:44:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Dec 2004 01:45:11 -0800 (PST) Received: from web41411.mail.yahoo.com (web41411.mail.yahoo.com [66.218.93.77]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iB29ix1n000503 for ; Thu, 2 Dec 2004 01:44:59 -0800 Received: (qmail 39134 invoked by uid 60001); 2 Dec 2004 09:44:33 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=k92BT0y43RKYSYKMggOHP5GR4uBRRgWyRcOAX5JmqyP/9qc7ObXyWrE7P9ymSzL+66OC8Ent972edeO7XCBfxbGmHyDKsnRKOhZZP1xOKL0zYIpVe3+rRwO6a4AMd3PpgkzKY/dpAceYFejgq5HEi0RIiLQRnYBcF1ypdL5sjWo= ; Message-ID: <20041202094433.39132.qmail@web41411.mail.yahoo.com> Received: from [202.56.231.117] by web41411.mail.yahoo.com via HTTP; Thu, 02 Dec 2004 01:44:33 PST Date: Thu, 2 Dec 2004 01:44:33 -0800 (PST) From: cranium2003 Subject: Maximum packet size in kernel To: kernerl mail Cc: net dev MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 12382 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cranium2003@yahoo.com Precedence: bulk X-list: netdev hello, I want to know how much maximum packet size is assigned by alloc_skb in kernel? and is there any extra space remains in packet allocated memory? Does it dependent on CPU cache? regards, cranium. __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com From rl@hellgate.ch Thu Dec 2 03:02:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Dec 2004 03:02:36 -0800 (PST) Received: from mail2.bluewin.ch (mail2.bluewin.ch [195.186.4.73]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB2B2TXn004351 for ; Thu, 2 Dec 2004 03:02:30 -0800 Received: from k3.hellgate.ch (83.77.143.24) by mail2.bluewin.ch (Bluewin AG 7.0.031.3) id 41888440002B727B; Thu, 2 Dec 2004 11:01:17 +0000 Received: by k3.hellgate.ch (Postfix, from userid 1000) id 8BCF691F5FB; Thu, 2 Dec 2004 12:01:20 +0100 (CET) Date: Thu, 2 Dec 2004 12:01:20 +0100 From: Roger Luethi To: Lennert Buytenhek Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: via-rhine unable to send back-to-back packets? Message-ID: <20041202110120.GA16597@k3.hellgate.ch> References: <20041129222700.GA22918@xi.wantstofly.org> <20041129172540.6b959858.davem@davemloft.net> <20041130064823.GA27872@xi.wantstofly.org> <20041130122503.0adac947.davem@davemloft.net> <20041130220644.GC29947@k3.hellgate.ch> <20041201200148.GE14470@xi.wantstofly.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041201200148.GE14470@xi.wantstofly.org> X-Operating-System: Linux 2.6.10-rc2-bk11 on i686 X-GPG-Fingerprint: 92 F4 DC 20 57 46 7B 95 24 4E 9E E7 5A 54 DC 1B X-GPG: 1024/80E744BD wwwkeys.ch.pgp.net User-Agent: Mutt/1.5.6i X-archive-position: 12383 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rl@hellgate.ch Precedence: bulk X-list: netdev [Thanks to A.J. from VNT for the answer which I am relaying below.] On Wed, 01 Dec 2004 21:01:48 +0100, Lennert Buytenhek wrote: > "Is the hardware capable of sending back-to-back packets (i.e. with > an inter-packet gap of no more than 96 bit times)?" => YES. All the VIA Rhine Fast Ethernet controllers follows the IEEE standard (inter-frame gap is 96 bit time) and it is hardware fixed and NOT programmable. > "Can misprogramming the chip lead to the effect that the inter-packet > gap is never less than 112 bit times?" => NO, it is fixed and neither software nor board level change could modify the inter-frame gap of VIA Rhine Fast Ethernet controller. > > Of course, you can always check if VIA's driver has the same issue. If > > it doesn't, chances are we can borrow the fix. > > Hmm, didn't know they had such a driver. Where can I find it? => in http://www.viaarena.com/ , choose "downloads" => "Drivers" => choose target OS (e.g. Fedora Core Linux) => "Ethernet (Networking/LAN)" => choose the type of your Ethernet controller => click to download the combo driver software package. From buytenh@wantstofly.org Thu Dec 2 03:09:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Dec 2004 03:10:04 -0800 (PST) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB2B9wjF004946 for ; Thu, 2 Dec 2004 03:09:59 -0800 Received: by xi.wantstofly.org (Postfix, from userid 500) id 17EA82B0ED; Thu, 2 Dec 2004 12:09:37 +0100 (MET) Date: Thu, 2 Dec 2004 12:09:37 +0100 From: Lennert Buytenhek To: Roger Luethi Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: via-rhine unable to send back-to-back packets? Message-ID: <20041202110937.GC24069@xi.wantstofly.org> References: <20041129222700.GA22918@xi.wantstofly.org> <20041129172540.6b959858.davem@davemloft.net> <20041130064823.GA27872@xi.wantstofly.org> <20041130122503.0adac947.davem@davemloft.net> <20041130220644.GC29947@k3.hellgate.ch> <20041201200148.GE14470@xi.wantstofly.org> <20041202110120.GA16597@k3.hellgate.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041202110120.GA16597@k3.hellgate.ch> User-Agent: Mutt/1.4.1i X-archive-position: 12384 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev On Thu, Dec 02, 2004 at 12:01:20PM +0100, Roger Luethi wrote: > On Wed, 01 Dec 2004 21:01:48 +0100, Lennert Buytenhek wrote: > > "Is the hardware capable of sending back-to-back packets (i.e. with > > an inter-packet gap of no more than 96 bit times)?" > > => YES. All the VIA Rhine Fast Ethernet controllers follows the IEEE > standard (inter-frame gap is 96 bit time) and it is hardware fixed and > NOT programmable. As far as I know, the IEEE standard only mandates a certain minimum inter-frame gap. Thanks for the information, I'll have a look at the VIA driver. --L From jgarzik@pobox.com Thu Dec 2 03:25:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Dec 2004 03:25:49 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB2BPgmF005571 for ; Thu, 2 Dec 2004 03:25:43 -0800 Received: from rdu74-155-169.nc.rr.com ([24.74.155.169] helo=[10.10.10.88]) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1CZp5N-00027Y-1w; Thu, 02 Dec 2004 11:25:21 +0000 Message-ID: <41AEFB95.8000100@pobox.com> Date: Thu, 02 Dec 2004 06:25:09 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] b44: allow ethtool get_settings when down References: <20041129094523.3185c64c@zqx3.pdx.osdl.net> In-Reply-To: <20041129094523.3185c64c@zqx3.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12385 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 Stephen Hemminger wrote: > The FC and Suse startup scripts use ethtool to check for link present. This has > problems on my laptop with Broadcom because it quieries settings before > bringing link up. The problem is driver returns EAGAIN when queried for > settings but not up. Just go ahead and return values anyway, the supported and link > state values will be correct, speed will end up being 10BaseT/Half which is a > reasonable default. > > Signed-off-by: Stephen Hemminger > > diff -Nru a/drivers/net/b44.c b/drivers/net/b44.c > --- a/drivers/net/b44.c 2004-11-29 09:41:27 -08:00 > +++ b/drivers/net/b44.c 2004-11-29 09:41:27 -08:00 > @@ -1487,8 +1487,6 @@ > { > struct b44 *bp = netdev_priv(dev); > > - if (!(bp->flags & B44_FLAG_INIT_COMPLETE)) > - return -EAGAIN; > cmd->supported = (SUPPORTED_Autoneg); > cmd->supported |= (SUPPORTED_100baseT_Half | > SUPPORTED_100baseT_Full | I'm not so sure about this one... This sounds like working around stupid userland in the kernel? Jeff From mellia@prezzemolo.polito.it Thu Dec 2 05:40:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Dec 2004 05:41:04 -0800 (PST) Received: from prezzemolo.polito.it (IDENT:root@prezzemolo.polito.it [130.192.9.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB2DeuAB012945 for ; Thu, 2 Dec 2004 05:40:57 -0800 Received: from mellia.lipar.polito.it ([192.168.85.105]) by prezzemolo.polito.it (8.12.10/8.12.10) with ESMTP id iB2DdWdW015837; Thu, 2 Dec 2004 14:39:35 +0100 Subject: Re: [E1000-devel] Transmission limit From: Marco Mellia Reply-To: mellia@prezzemolo.polito.it To: hadi@cyberus.ca Cc: mellia@prezzemolo.polito.it, Lennert Buytenhek , Harald Welte , P@draigBrady.com, e1000-devel@lists.sourceforge.net, Jorge Manuel Finochietto , Giulio Galante , netdev@oss.sgi.com In-Reply-To: <1101903944.1042.29.camel@jzny.localdomain> References: <1101467291.24742.70.camel@mellia.lipar.polito.it> <41A73826.3000109@draigBrady.com> <1101483081.24742.174.camel@mellia.lipar.polito.it> <20041127092503.GA12592@sunbeam.de.gnumonks.org> <1101718412.14930.46.camel@verza.polito.it> <20041129145028.GC18788@xi.wantstofly.org> <1101804146.11111.23.camel@mellia.lipar.polito.it> <1101903944.1042.29.camel@jzny.localdomain> Content-Type: text/plain Organization: Message-Id: <1101994772.18491.16.camel@mellia.lipar.polito.it> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 02 Dec 2004 14:39:32 +0100 Content-Transfer-Encoding: 7bit X-TLC-MailScanner-Information: Please contact the ISP for more information X-TLC-MailScanner: Found to be clean X-TLC-MailScanner-SpamCheck: not spam, SpamAssassin (score=-4.785, required 5.5, AWL 0.12, BAYES_00 -4.90) X-archive-position: 12386 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mellia@prezzemolo.polito.it Precedence: bulk X-list: netdev > > > > We are thinking of sending packet in "bursts" instead of single > > > > transfers. The only problem is to let the NIC know that there are more > > > > than a packet in a burst... > > > > > > Jamal implemented exactly this for e1000 already, he might be persuaded > > > into posting his patch here. Jamal? :) > > > > I guess that saying that we are _very_ interested in this might help. > > :-) > > We can offer as "beta-testers" as well... > > Sorry missed this (I wasnt CCed so it went to a low priority queue which > i read on a best effort basis). > Let me clean up the patches a little bit this weekend. The patch is at > least 4 months old; latest reincarnation was due to issue1 on my SUCON > presentation. Would a patch against latest 2.6.x bitkeeper (whatever it > is this weekend) be fine? If you are in a rush and dont mind a little > ugliness then i will pass them as is. > We'll be glad to spend some time trying this out. Please, we are not very confortable with the linux bitkeeper maintenance method. Can we ask you to provide us a patch to a standard kernel/driver (whatever you prefer...)? Also a complete source sub-tree would be ok ;-) > BTW, Scott posted a interesting patch yesterday, you may wanna give that > a shot as well. We're trying that out right now... (which means, that in a couple of days, we'll try it ;-)) Thanks a lot. -- Ciao, /\/\/\rco +-----------------------------------+ | Marco Mellia - Assistant Professor| | Tel: 39-011-2276-608 | | Tel: 39-011-564-4173 | | Cel: 39-340-9674888 | /"\ .. . . . . . . . . . . . . | Politecnico di Torino | \ / . ASCII Ribbon Campaign . | Corso Duca degli Abruzzi 24 | X .- NO HTML/RTF in e-mail . | Torino - 10129 - Italy | / \ .- NO Word docs in e-mail. | http://www1.tlc.polito.it/mellia | .. . . . . . . . . . . . . +-----------------------------------+ The box said "Requires Windows 95 or Better." So I installed Linux. From wensong@linux-vs.org Thu Dec 2 06:53:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Dec 2004 06:53:22 -0800 (PST) Received: from lb1.ctrip.com ([218.244.111.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB2ErDuh020118 for ; Thu, 2 Dec 2004 06:53:15 -0800 Received: from penguin.linux-vs.org ([61.149.157.27]) by lb1.ctrip.com (8.12.10/8.12.10) with ESMTP id iB2EpwMh015802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Dec 2004 22:52:06 +0800 Received: from penguin.linux-vs.org (localhost.localdomain [127.0.0.1]) by penguin.linux-vs.org (8.12.8/8.12.8) with ESMTP id iB2EpiPX001140; Thu, 2 Dec 2004 22:51:44 +0800 Received: from localhost (wensong@localhost) by penguin.linux-vs.org (8.12.8/8.12.8/Submit) with ESMTP id iB2EpZmc001136; Thu, 2 Dec 2004 22:51:40 +0800 X-Authentication-Warning: penguin.linux-vs.org: wensong owned process doing -bs Date: Thu, 2 Dec 2004 22:51:34 +0800 (CST) From: Wensong Zhang To: Horms cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] [IPVS] add a sysctl variable to expire quiescent template In-Reply-To: <20041202040717.GF32190@verge.net.au> Message-ID: References: <20041202040717.GF32190@verge.net.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 12387 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wensong@linux-vs.org Precedence: bulk X-list: netdev On Thu, 2 Dec 2004, Horms wrote: > On Thu, Dec 02, 2004 at 12:48:26AM +0800, Wensong Zhang wrote: >> >> >> Hi Dave, >> >> Here is the patch from Horms to add a sysctl >> variable to expire quiescent templat. Please check and apply them to >> kernel 2.4 and 2.6 respectively. >> >> Thanks, >> >> Wensong > > I can do this too, just in case you need it. > > Signed-off-by: Horms > Sure. :) I will ask you to make the patches for kernel 2.4 and 2.6 next time, and I just need to verify and test them. :) Cheers, Wensong From mellia@prezzemolo.polito.it Thu Dec 2 09:26:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Dec 2004 09:26:16 -0800 (PST) Received: from prezzemolo.polito.it (IDENT:root@prezzemolo.polito.it [130.192.9.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB2HQ8oi027479 for ; Thu, 2 Dec 2004 09:26:09 -0800 Received: from mellia.lipar.polito.it ([192.168.85.105]) by prezzemolo.polito.it (8.12.10/8.12.10) with ESMTP id iB2HOYdW032567; Thu, 2 Dec 2004 18:24:49 +0100 Subject: Re: [E1000-devel] Transmission limit From: Marco Mellia Reply-To: mellia@prezzemolo.polito.it To: hadi@cyberus.ca Cc: mellia@prezzemolo.polito.it, P@draigBrady.com, e1000-devel@lists.sourceforge.net, Jorge Manuel Finochietto , Giulio Galante , netdev@oss.sgi.com In-Reply-To: <1101822364.1044.60.camel@jzny.localdomain> References: <1101467291.24742.70.camel@mellia.lipar.polito.it> <41A73826.3000109@draigBrady.com> <1101483081.24742.174.camel@mellia.lipar.polito.it> <1101498963.1076.39.camel@jzny.localdomain> <1101738118.14930.142.camel@verza.polito.it> <1101822364.1044.60.camel@jzny.localdomain> Content-Type: text/plain Organization: Message-Id: <1102008274.19646.14.camel@mellia.lipar.polito.it> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 02 Dec 2004 18:24:34 +0100 Content-Transfer-Encoding: 7bit X-TLC-MailScanner-Information: Please contact the ISP for more information X-TLC-MailScanner: Found to be clean X-TLC-MailScanner-SpamCheck: not spam, SpamAssassin (score=-4.788, required 5.5, AWL 0.11, BAYES_00 -4.90) X-archive-position: 12388 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mellia@prezzemolo.polito.it Precedence: bulk X-list: netdev > > In our experiments, we modified the kernel to drop packets just after > > receiving them. skb are just deallocated (using standerd kernel > > routines, i.e., no recycling is used). Logically, that happen when the > > netif_rx() is called. > > > > Now, we have three cases > > 1) just mofify the netif_rx() to drop packets. > > 2) as in one, plus remove the protocol check in the driver > > (i.e., comment the line > > skb->protocol = eth_type_trans(skb, netdev); > > ) to avoid to access the real packet data. > > 3) as in 2, but dealloc is performed at the driver level, instead of > > calling the netif_rx() > > > > In the first case, we can receive about 1.1Mpps (~80% of packets) > > Possible. I was able to receive 900Kpps or so in my experiments with > gact drop which is slightly above this with a 2.4 Ghz machine with IRQ > affinity. I double checked with the people that actually did the job. They indeed tested both cases, i.e., dropping packets either using IRQ (therefore using netif_rx()) or using NAPI (therefore using netif_receive_skb()). In both cases, disabling the eth_type_trans() check, we receive 100% of packets... > > In the third case, we can NOT receive 100% of packets! > > The only difference is that we actually _REMOVED_ a funcion call. This > > reduces the overhead, and the compiler/cpu/whatever can not optimize the > > data path to access to the skb which must be freed. > > It doesnt seem like you were runing NAPI if you depended on calling > netif_rx > In that case, #3 would be freeing in hard IRQ context while #2 is > softIRQ. Again, it was my mistake. Case #3 was performed using the NAPI stack, i.e., freeing up skb instead of calling the netif_receive_skb(). Doing that, we observed a performance drop, that we hint to some caching isses. Indeed, investigating with a Oprofile, in case #3 it registers about twice the number of cache miss than in case #2. Again, we do not have any plain explanation, but our intuition is that adding a function call with pointer as argument might allow the compiler/cpu to prefecth the skb and speed up the memory release... > > Our guess is that by freeing up the skb in the netif_rx() function > > actually allows the compiler/cpu to prefetch the skb itself, and > > therefore keep the pipeline working... > > > > My guess is that if you change compiler, cpu, memory subsystem, you may > > get very counterintuitive results... > > Refer to my comment above. > Repeat tests with NAPI and see if you get same results. We were using NAPI. Sorry for the misunderstanding. Hope this helps. -- Ciao, /\/\/\rco +--+ | Marco Mellia - Assistant Professor| | Tel: 39-011-2276-608 | | Tel: 39-011-564-4173 | | Cel: 39-340-9674888 | /"\ .. . . . . . . . . . . . . | Politecnico di Torino | \ / . ASCII Ribbon Campaign . | Corso Duca degli Abruzzi 24 | X .- NO HTML/RTF in e-mail . | Torino - 10129 - Italy | / \ .- NO Word docs in e-mail. | http://www1.tlc.polito.it/mellia | .. . . . . . . . . . . . . +--+ The box said "Requires Windows 95 or Better." So I installed Linux. From sjackman@gmail.com Thu Dec 2 09:28:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Dec 2004 09:29:04 -0800 (PST) Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.244]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB2HSxL0027742 for ; Thu, 2 Dec 2004 09:28:59 -0800 Received: by mproxy.gmail.com with SMTP id w41so155372cwb for ; Thu, 02 Dec 2004 09:28:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=tt+V2mOZVtqNGj2lUTzutEa6y3bD2GO0hWS5b6Xur4NSQ2logiGPSVmg9tnuVxTgrY0xztUkGWxBv96sLTt11zWL2ksmpN/pd54vyP9sNEko8JgvzIXwJaePCalzBBPVOwGV8Yhvuj/nO6Li+oeAl6NTpGyqMEDf2axP1uCdbWQ= Received: by 10.11.116.64 with SMTP id o64mr418223cwc; Thu, 02 Dec 2004 09:28:36 -0800 (PST) Received: by 10.11.99.50 with HTTP; Thu, 2 Dec 2004 09:28:36 -0800 (PST) Message-ID: <7f45d9390412020928f298944@mail.gmail.com> Date: Thu, 2 Dec 2004 09:28:36 -0800 From: Shaun Jackman Reply-To: Shaun Jackman To: netdev@oss.sgi.com Subject: Re: Multicast filtering for tun.c [PATCH] In-Reply-To: <20041201233400.45078efe.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <7f45d9390411251715138b35d0@mail.gmail.com> <20041127011006.03232bb6.akpm@osdl.org> <7f45d939041201140329d0273f@mail.gmail.com> <20041201233400.45078efe.akpm@osdl.org> X-archive-position: 12389 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sjackman@gmail.com Precedence: bulk X-list: netdev Thanks for your careful review, Andrew. I appreciate your help. > You're sure this shouldn't be using crc-ccitt? I used ether_crc because every driver in drivers/net except ppp_async.c does. Either would work as long as the chosen hash function is used consistently. > del_multi(u32 *filter, const u8 *addr) > > would be a more typical layout. I prefer the asterisk with the rest of the type information, but I know the latter is more typical. Fixed. > > + const u8 ones[ ETH_ALEN] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; > > The space after the `[' is gratuitous. > > This array will be allocated onthe stack and populated by hand each time > this function is called. It should be made static. > > > + u8 addr[ ETH_ALEN]; > > extraneous space. Fixed. > > + memcpy(addr, skb->data, min(sizeof addr, skb->len)); > > We normally put parentheses around the argument of the sizeof operator, for > no particular reason ;) > > > + if (copy_from_user(&ifr, argp, sizeof ifr)) > > Ditto I prefer not to add the extraneous punctuation. I find it makes it harder to read. > > + case SIOCGIFFLAGS: > > + ifr.ifr_flags = tun->if_flags; > > + if (copy_to_user( argp, &ifr, sizeof ifr)) > > extraneous space. > > > + if (copy_to_user( argp, &ifr, sizeof ifr)) > > ditto Fixed. > > + DBG(KERN_DEBUG "%s: add multi: %x:%x:%x:%x:%x:%x\n", > > + tun->dev->name, > > + (u8)ifr.ifr_hwaddr.sa_data[0], (u8)ifr.ifr_hwaddr.sa_data[1], > > + (u8)ifr.ifr_hwaddr.sa_data[2], (u8)ifr.ifr_hwaddr.sa_data[3], > > + (u8)ifr.ifr_hwaddr.sa_data[4], (u8)ifr.ifr_hwaddr.sa_data[5]); > > Why all the typecasts? [clip] > ditto. sa_data is signed for some reason, which causes the signed byte to be sign extended resulting in the mac address being printed as 0:c:6e:14:ffffffa0:5a, for example. Here's a short diff of the changes to my patch. The full patch follows. 27c27 < +add_multi(u32* filter, const u8* addr) --- > +add_multi(u32 *filter, const u8 *addr) 38c38 < +del_multi(u32* filter, const u8* addr) --- > +del_multi(u32 *filter, const u8 *addr) 71,72c71,72 < + const u8 ones[ ETH_ALEN] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; < + u8 addr[ ETH_ALEN]; --- > + static const u8 ones[ETH_ALEN] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; > + u8 addr[ETH_ALEN]; 137c137 < + void __user* argp = (void __user*)arg; --- > + void __user *argp = (void __user*)arg; 168c168 < + if (copy_to_user( argp, &ifr, sizeof ifr)) --- > + if (copy_to_user(argp, &ifr, sizeof ifr)) 183c183 < + if (copy_to_user( argp, &ifr, sizeof ifr)) --- > + if (copy_to_user(argp, &ifr, sizeof ifr)) Cheers, Shaun 2004-11-25 Shaun Jackman * drivers/net/tun.c: Add multicast filtering for packets travelling from the network device to the character device. * include/linux/if_tun.h (tun_struct): Add interface flags, a hardware device addres, and a multicast filter. diff -ur linux-2.6.8.1.orig/drivers/net/tun.c linux-2.6.8.1/drivers/net/tun.c --- linux-2.6.8.1.orig/drivers/net/tun.c 2004-08-14 03:55:23.000000000 -0700 +++ linux-2.6.8.1/drivers/net/tun.c 2004-11-25 17:00:22.000000000 -0800 @@ -41,6 +41,7 @@ #include #include #include +#include #include #include @@ -104,11 +105,42 @@ return 0; } -static void tun_net_mclist(struct net_device *dev) +/** Add the specified Ethernet address to this multicast filter. */ +static void +add_multi(u32 *filter, const u8 *addr) { - /* Nothing to do for multicast filters. - * We always accept all frames. */ - return; + int bit_nr = ether_crc(ETH_ALEN, addr) >> 26; + filter[bit_nr >> 5] |= 1 << (bit_nr & 31); +} + +/** Remove the specified Ethernet addres from this multicast filter. */ +static void +del_multi(u32 *filter, const u8 *addr) +{ + int bit_nr = ether_crc(ETH_ALEN, addr) >> 26; + filter[bit_nr >> 5] &= ~(1 << (bit_nr & 31)); +} + +/** Update the list of multicast groups to which the network device belongs. + * This list is used to filter packets being sent from the character device to + * the network device. */ +static void +tun_net_mclist(struct net_device *dev) +{ + struct tun_struct *tun = netdev_priv(dev); + const struct dev_mc_list *mclist; + int i; + DBG(KERN_DEBUG "%s: tun_net_mclist: mc_count %d\n", + dev->name, dev->mc_count); + memset(tun->chr_filter, 0, sizeof tun->chr_filter); + for (i = 0, mclist = dev->mc_list; i < dev->mc_count && mclist != NULL; + i++, mclist = mclist->next) { + add_multi(tun->net_filter, mclist->dmi_addr); + DBG(KERN_DEBUG "%s: tun_net_mclist: %x:%x:%x:%x:%x:%x\n", + dev->name, + mclist->dmi_addr[0], mclist->dmi_addr[1], mclist->dmi_addr[2], + mclist->dmi_addr[3], mclist->dmi_addr[4], mclist->dmi_addr[5]); + } } static struct net_device_stats *tun_net_stats(struct net_device *dev) @@ -301,6 +333,10 @@ add_wait_queue(&tun->read_wait, &wait); while (len) { + static const u8 ones[ETH_ALEN] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; + u8 addr[ETH_ALEN]; + int bit_nr; + current->state = TASK_INTERRUPTIBLE; /* Read frames from the queue */ @@ -320,10 +356,37 @@ } netif_start_queue(tun->dev); - ret = tun_put_user(tun, skb, (struct iovec *) iv, len); - - kfree_skb(skb); - break; + /** Decide whether to accept this packet. This code is designed to + * behave identically to an Ethernet interface. Accept the packet if + * - we are promiscuous. + * - the packet is addressed to us. + * - the packet is broadcast. + * - the packet is multicast and + * - we are multicast promiscous. + * - we belong to the multicast group. + */ + memcpy(addr, skb->data, min(sizeof addr, skb->len)); + bit_nr = ether_crc(sizeof addr, addr) >> 26; + if ((tun->if_flags & IFF_PROMISC) || + memcmp(addr, tun->dev_addr, sizeof addr) == 0 || + memcmp(addr, ones, sizeof addr) == 0 || + (((addr[0] == 1 && addr[1] == 0 && addr[2] == 0x5e) || + (addr[0] == 0x33 && addr[1] == 0x33)) && + ((tun->if_flags & IFF_ALLMULTI) || + (tun->chr_filter[bit_nr >> 5] & (1 << (bit_nr & 31)))))) { + DBG(KERN_DEBUG "%s: tun_chr_readv: accepted: %x:%x:%x:%x:%x:%x\n", + tun->dev->name, addr[0], addr[1], addr[2], + addr[3], addr[4], addr[5]); + ret = tun_put_user(tun, skb, (struct iovec *) iv, len); + kfree_skb(skb); + break; + } else { + DBG(KERN_DEBUG "%s: tun_chr_readv: rejected: %x:%x:%x:%x:%x:%x\n", + tun->dev->name, addr[0], addr[1], addr[2], + addr[3], addr[4], addr[5]); + kfree_skb(skb); + continue; + } } current->state = TASK_RUNNING; @@ -417,6 +480,12 @@ tun = netdev_priv(dev); tun->dev = dev; tun->flags = flags; + /* Be promiscuous by default to maintain previous behaviour. */ + tun->if_flags = IFF_PROMISC; + /* Generate random Ethernet address. */ + *(u16 *)tun->dev_addr = htons(0x00FF); + get_random_bytes(tun->dev_addr + sizeof(u16), 4); + memset(tun->chr_filter, 0, sizeof tun->chr_filter); tun_net_init(dev); @@ -457,13 +526,16 @@ unsigned int cmd, unsigned long arg) { struct tun_struct *tun = file->private_data; + void __user *argp = (void __user*)arg; + struct ifreq ifr; + + if (cmd == TUNSETIFF || _IOC_TYPE(cmd) == 0x89) + if (copy_from_user(&ifr, argp, sizeof ifr)) + return -EFAULT; if (cmd == TUNSETIFF && !tun) { - struct ifreq ifr; int err; - if (copy_from_user(&ifr, (void __user *)arg, sizeof(ifr))) - return -EFAULT; ifr.ifr_name[IFNAMSIZ-1] = '\0'; rtnl_lock(); @@ -473,7 +545,7 @@ if (err) return err; - if (copy_to_user((void __user *)arg, &ifr, sizeof(ifr))) + if (copy_to_user(argp, &ifr, sizeof(ifr))) return -EFAULT; return 0; } @@ -519,6 +591,61 @@ break; #endif + case SIOCGIFFLAGS: + ifr.ifr_flags = tun->if_flags; + if (copy_to_user(argp, &ifr, sizeof ifr)) + return -EFAULT; + return 0; + + case SIOCSIFFLAGS: + /** Set the character device's interface flags. Currently only + * IFF_PROMISC and IFF_ALLMULTI are used. */ + tun->if_flags = ifr.ifr_flags; + DBG(KERN_INFO "%s: interface flags 0x%lx\n", + tun->dev->name, tun->if_flags); + return 0; + + case SIOCGIFHWADDR: + memcpy(ifr.ifr_hwaddr.sa_data, tun->dev_addr, + min(sizeof ifr.ifr_hwaddr.sa_data, sizeof tun->dev_addr)); + if (copy_to_user(argp, &ifr, sizeof ifr)) + return -EFAULT; + return 0; + + case SIOCSIFHWADDR: + /** Set the character device's hardware address. This is used when + * filtering packets being sent from the network device to the character + * device. */ + memcpy(tun->dev_addr, ifr.ifr_hwaddr.sa_data, + min(sizeof ifr.ifr_hwaddr.sa_data, sizeof tun->dev_addr)); + DBG(KERN_DEBUG "%s: set hardware address: %x:%x:%x:%x:%x:%x\n", + tun->dev->name, + tun->dev_addr[0], tun->dev_addr[1], tun->dev_addr[2], + tun->dev_addr[3], tun->dev_addr[4], tun->dev_addr[5]); + return 0; + + case SIOCADDMULTI: + /** Add the specified group to the character device's multicast filter + * list. */ + add_multi(tun->chr_filter, ifr.ifr_hwaddr.sa_data); + DBG(KERN_DEBUG "%s: add multi: %x:%x:%x:%x:%x:%x\n", + tun->dev->name, + (u8)ifr.ifr_hwaddr.sa_data[0], (u8)ifr.ifr_hwaddr.sa_data[1], + (u8)ifr.ifr_hwaddr.sa_data[2], (u8)ifr.ifr_hwaddr.sa_data[3], + (u8)ifr.ifr_hwaddr.sa_data[4], (u8)ifr.ifr_hwaddr.sa_data[5]); + return 0; + + case SIOCDELMULTI: + /** Remove the specified group from the character device's multicast + * filter list. */ + del_multi(tun->chr_filter, ifr.ifr_hwaddr.sa_data); + DBG(KERN_DEBUG "%s: del multi: %x:%x:%x:%x:%x:%x\n", + tun->dev->name, + (u8)ifr.ifr_hwaddr.sa_data[0], (u8)ifr.ifr_hwaddr.sa_data[1], + (u8)ifr.ifr_hwaddr.sa_data[2], (u8)ifr.ifr_hwaddr.sa_data[3], + (u8)ifr.ifr_hwaddr.sa_data[4], (u8)ifr.ifr_hwaddr.sa_data[5]); + return 0; + default: return -EINVAL; }; diff -ur linux-2.6.8.1.orig/include/linux/if_tun.h linux-2.6.8.1/include/linux/if_tun.h --- linux-2.6.8.1.orig/include/linux/if_tun.h 2004-08-14 03:55:09.000000000 -0700 +++ linux-2.6.8.1/include/linux/if_tun.h 2004-11-25 16:47:31.000000000 -0800 @@ -45,6 +45,11 @@ struct fasync_struct *fasync; + unsigned long if_flags; + u8 dev_addr[ETH_ALEN]; + u32 chr_filter[2]; + u32 net_filter[2]; + #ifdef TUN_DEBUG int debug; #endif From mellia@prezzemolo.polito.it Thu Dec 2 09:33:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Dec 2004 09:33:34 -0800 (PST) Received: from prezzemolo.polito.it (IDENT:root@prezzemolo.polito.it [130.192.9.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB2HXSrW028218 for ; Thu, 2 Dec 2004 09:33:28 -0800 Received: from mellia.lipar.polito.it ([192.168.85.105]) by prezzemolo.polito.it (8.12.10/8.12.10) with ESMTP id iB2HVUdW000522; Thu, 2 Dec 2004 18:31:30 +0100 Subject: Re: [E1000-devel] Transmission limit From: Marco Mellia Reply-To: mellia@prezzemolo.polito.it To: sfeldma@pobox.com Cc: birke@serveliper.polito.it, Lennert Buytenhek , jamal , Robert Olsson , P@draigBrady.com, mellia@prezzemolo.polito.it, e1000-devel@lists.sourceforge.net, Jorge Manuel Finochietto , Giulio Galante , netdev@oss.sgi.com In-Reply-To: <1101863399.4663.54.camel@sfeldma-mobl.dsl-verizon.net> References: <1101467291.24742.70.camel@mellia.lipar.polito.it> <41A73826.3000109@draigBrady.com> <16807.20052.569125.686158@robur.slu.se> <1101484740.24742.213.camel@mellia.lipar.polito.it> <41A76085.7000105@draigBrady.com> <1101499285.1079.45.camel@jzny.localdomain> <16811.8052.678955.795327@robur.slu.se> <1101821501.1043.43.camel@jzny.localdomain> <20041130134600.GA31515@xi.wantstofly.org> <1101824754.1044.126.camel@jzny.localdomain> <20041201001107.GE4203@xi.wantstofly.org> <1101863399.4663.54.camel@sfeldma-mobl.dsl-verizon.net> Content-Type: text/plain Organization: Message-Id: <1102008690.19646.22.camel@mellia.lipar.polito.it> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 02 Dec 2004 18:31:30 +0100 Content-Transfer-Encoding: 7bit X-TLC-MailScanner-Information: Please contact the ISP for more information X-TLC-MailScanner: Found to be clean X-TLC-MailScanner-SpamCheck: not spam, SpamAssassin (score=-4.788, required 5.5, AWL 0.11, BAYES_00 -4.90) X-archive-position: 12390 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mellia@prezzemolo.polito.it Precedence: bulk X-list: netdev On Wed, 2004-12-01 at 02:09, Scott Feldman wrote: > Hey, turns out, I know some e1000 tricks that might help get the kpps > numbers up. > > My problem is I only have a P4 desktop system with a 82544 nic r