Re: NAPI-ized tulip patch against 2.4.20-rc1

[Robert Olsson <Robert.Olsson@data.slu.se>]

Ben Greear writes:

 > >  I see you increased the RX-ring to 1024 pkts. 
 > >  Did you really see any improvement with this?
 > 
 > It helped drop fewer packets when running 4 ports at 92Mbps+
 > However, the difference between that and 512 is not large.
 > I would really like to make that size adjustable at module load
 > time and/or runtime, but I'm not sure how easy that would be.
 > 
 > Imagine being able to crank up your receive buffers when running at
 > very high speeds (and/or when you start dropping packets).  At lower speeds,
 > shrink things down and free up resources....

 I still doubt ;-) 

 With e1000 I played with various settings for RX-buffers rather recently 
 when the 82544 increased the number of available buffers from 256 to 4096.

 And I guess my test looks a bit like yours... Injecting an "overload" of 
 packets. I found was 256 buffers was the optimum. Approximative of course.
 
 
 > Were you testing SMP or uni-processor?  I've been doing the tulip testing
 > on a single processor P-IV system.

 We tested both at that time but it's rewritten now... 

 And as you saw for SMP with recycle it is easy to feed the recycled skb 
 back to CPU were it was created/processed.

 So kfree/skb_headerinit "should" cause less cache bouncing. Still we need
 to pollute one cache line to find the CPU "owner". I posted some of 
 numbers here time ago but it would be nice to verify with CPU's performance 
 counters.


 Cheers.

						--ro