On Fri, Aug 19, 2005 at 07:05:06PM +0200, Andi Kleen wrote: > > Right. The other issue with jumbos frames (9000MTU) is that > > the allocation needed is just over 2 pages for 4K page size > > machines (common case). 3 page contig allocations tend to fail > > once a server is heavily loaded and memory gets fragmented. > > That's just a driver bug. The driver should be splitting up the > buffers into page sized chunks. TX does that already, but > for RX the driver needs to do it.
The problem with the e1000 driver in this regard is the following: 1. It internally rounds the Rx buffer up to the next power of 2 So your 9k MTU request just turned into a 16k (16384) allocation 2. alloc_skb() allocates size+sizeof(struct skb_shared_info) bytes using kmalloc(), which bumps the size over the power-of-2 boundary 3. kmalloc() rounds this up to the next power of 2, and you end up with a 32k (yes, a 32768 byte) GFP_ATOMIC allocation request. I tested the version in 2.4.26 (version 5.2.30.1-k1) and the one from Intel's webpage (6.1.16) on 2.4.26. Is there any plans to fix this? Does the 2.4 kernel support chained sk_buff's along the receive path? (This is news to me!) Is there any driver that does this, that can be read as an instructive example? Thanks, Guy Thornley - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
