Pulling Rx Polling has kept V2.6 from dropping packets. argh?!?!?! I should
have caught that sooner. 8( Well, I have a window of opportunity here. If
you want I can still provide a broken environment but that seems pointless
while NAPI is not acting right... what is evident is that this will run
better till we start to bump up against the top of CPU0.
On Thursday 06 January 2005 02:29 pm, Robert Olsson wrote:
> Jeremy M. Guthrie writes:
> > > You only use CPU0 for packet processing. Also it seems you use the
> > > non-NAPI version of e1000.
> > The E1000 driver is the stock driver in 2.4.28.
> There is a kernel config option. Use Rx Polling (NAPI)
> > eth2 is TX only. We don't receive anything on it. This system should
> > only ever RX on eth3 and TX on eth2 as part of its function.
> Ok! So unidirectional traffic and CPU0 processes all skb's and passes them
> over to CPU1 which touches and frees them. You could try some other
> affinity setting later on but there are so many options depending what
> we want do. If we just want to compare 2.4/2.6 we can start out simple
> with setting affinity so only one CPU. Which is almost what you got.
> We reach all the complicated problems immediately... Now we pass skb's
> between the CPU's which release cache bouncing and makes slab rebalance
> it's pools. So using just one CPU is probably better... If we had incoming
> pkts on eth2 eventually we could have had any use for CPU1.
> Install NAPI-driver, set affinity so eth2/eth3 uses same CPU to start
> The stats info you sent was almost impossible to read. See if you can get
> only the rtstats.
Jeremy M. Guthrie jeremy.guthrie@xxxxxxxxxx
Senior Network Engineer Phone: 608-298-1061
Berbee Fax: 608-288-3007
5520 Research Park Drive NOC: 608-298-1102
Madison, WI 53711
Description: PGP signature