Received: with ECARTIS (v1.0.0; list netdev); Sat, 23 Apr 2005 10:54:36 -0700 (PDT) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j3NHsVdD010972 for ; Sat, 23 Apr 2005 10:54:32 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j3NHsDr0011526; Sat, 23 Apr 2005 19:54:14 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id CE739EE1E9; Sat, 23 Apr 2005 19:54:13 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17002.35781.813292.517029@robur.slu.se> Date: Sat, 23 Apr 2005 19:54:13 +0200 To: Stephen Hemminger Cc: "David S. Miller" , gnb@sgi.com, hadi@cyberus.ca, ak@muc.de, akepner@sgi.com, jesse.brandeburg@intel.com, netdev@oss.sgi.com, davem@redhat.com Subject: Re: NAPI, e100, and system performance problem In-Reply-To: <20050423125153.65189ea0@localhost.localdomain> References: <1113855967.7436.39.camel@localhost.localdomain> <20050419055535.GA12211@sgi.com> <1114173195.7679.30.camel@localhost.localdomain> <20050422172108.GA10598@muc.de> <1114193902.7978.39.camel@localhost.localdomain> <20050422232831.GB6462@sgi.com> <20050423094038.72a8da73@localhost.localdomain> <20050422164301.724343f6.davem@davemloft.net> <20050423125153.65189ea0@localhost.localdomain> X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV 0.83/849/Fri Apr 22 08:52:53 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 343 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 1073 Lines: 26 Stephen Hemminger writes: > One of the problem with the dynamic schemes, is there is no generic infrastructure > to support it. There are some drivers that have tried dynamic schemes > but each seems to reinvent some adhoc scheme. Seems like a good area > for future research. Well how do decorrelate bursty network and more interesing at what time level? I said this before... the only useful measure for mitigation setting was packets on RX ring. > Another related problem is some drivers use NAPI for both TX and RX and > this can cause asymmetric behavior and scheduling issues. The whole > dev->weight limit stuff assumes RX not TX usage of NAPI Well in the very beginning it was thought only RX yes, But it is possible also to have TX buffer cleared etc in the ->poll routine to simplify intr. acking. As implemented only RX packets updates the budget. From what I see in real life use this works well. Guess you noticed the tests with e1000 and TCP just posted. Anyway MSI will give us some new options in this area.. Cheers. --ro