From mboxrd@z Thu Jan 1 00:00:00 1970 From: jamal Subject: Re: RFC: NAPI packet weighting patch Date: Tue, 07 Jun 2005 09:29:08 -0400 Message-ID: <1118150948.6320.152.camel@localhost.localdomain> References: <468F3FDA28AA87429AD807992E22D07E0450C00B@orsmsx408> <42A5284C.3060808@osdl.org> <1118147904.6320.108.camel@localhost.localdomain> Reply-To: hadi@cyberus.ca Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Stephen Hemminger , Mitch Williams , "Ronciak, John" , "David S. Miller" , mchan@broadcom.com, buytenh@wantstofly.org, jdmason@us.ibm.com, netdev@oss.sgi.com, Robert.Olsson@data.slu.se, "Venkatesan, Ganesh" , "Brandeburg, Jesse" Return-path: To: Martin Josefsson In-Reply-To: Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com List-Id: netdev.vger.kernel.org On Tue, 2005-07-06 at 14:06 +0200, Martin Josefsson wrote: > One thing that jumps to mind is that e1000 starts at lastrxdescriptor+1 > and loops and checks the status of each descriptor and stops when it finds > a descriptor that isn't finished. Another way to do it is to read out the > current position of the ring and loop from lastrxdescriptor+1 up to the > current position. Scott Feldman implemented this for TX and there it > increased performance somewhat (discussed here on netdev some months ago). > I wonder if it could also decrease RX latency, I mean, we have to get the > cache miss sometime anyway. > The effect of Scotts patch was to reduce IO by amortizing it on the TX side. Are we talking about the same thing ? This was in the case of TX descriptor prunning? So it is possible that the e1000 is doing more than necessary share of IO on the receive side as well. cheers, jamal