Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jun 2005 14:01:04 -0700 (PDT) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j53L0nXq004267 for ; Fri, 3 Jun 2005 14:00:50 -0700 Received: by xi.wantstofly.org (Postfix, from userid 500) id 5F5B5945C8; Fri, 3 Jun 2005 22:59:45 +0200 (MEST) Date: Fri, 3 Jun 2005 22:59:45 +0200 From: Lennert Buytenhek To: Michael Chan Cc: "David S. Miller" , mitch.a.williams@intel.com, hadi@cyberus.ca, john.ronciak@intel.com, jdmason@us.ibm.com, shemminger@osdl.org, netdev@oss.sgi.com, Robert.Olsson@data.slu.se, ganesh.venkatesan@intel.com, jesse.brandeburg@intel.com Subject: Re: RFC: NAPI packet weighting patch Message-ID: <20050603205944.GC20623@xi.wantstofly.org> References: <20050603.120126.41874584.davem@davemloft.net> <20050603.132257.23013342.davem@davemloft.net> <20050603.132922.63997492.davem@davemloft.net> <1117828169.4430.29.camel@rh4> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1117828169.4430.29.camel@rh4> User-Agent: Mutt/1.4.1i X-archive-position: 2065 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 Content-Length: 873 Lines: 22 On Fri, Jun 03, 2005 at 12:49:29PM -0700, Michael Chan wrote: > > E1000 processes the full QUOTA of RX packets, > > _THEN_ replenishes with new RX buffers. No wonder > > the chip runs out of RX descriptors. > > > > You should replenish _AS_ you grab RX packets > > off the receive queue, just as tg3 does. > > Yes, in tg3, rx buffers are replenished and put back into the ring > as completed packets are taken off the ring. But we don't tell the > chip about these new buffers until we get to the end of the loop, > potentially after a full quota of packets. Which makes a lot more sense, since you'd rather do one MMIO write at the end of the loop than one per iteration, especially if your MMIO read (flush) latency is high. (Any subsequent MMIO read will have to flush out all pending writes, which'll be slow if there's a lot of writes still in the queue.) --L