On Sat, Jan 05, 2013 at 06:22:13PM -0800, Eric Dumazet wrote: > On Sun, 2013-01-06 at 03:18 +0100, Willy Tarreau wrote: > > On Sat, Jan 05, 2013 at 06:16:31PM -0800, Eric Dumazet wrote: > > > On Sat, 2013-01-05 at 17:51 -0800, Eric Dumazet wrote: > > > > On Sat, 2013-01-05 at 17:40 -0800, Eric Dumazet wrote: > > > > > On Sun, 2013-01-06 at 02:30 +0100, Willy Tarreau wrote: > > > > > > > > > > > Ah interesting because these were some of the mm patches that I had > > > > > > tried to revert. > > > > > > > > > > Hmm, or we should fix __skb_splice_bits() > > > > > > > > > > I'll send a patch. > > > > > > > > > > > > > Could you try the following ? > > > > > > Or more exactly... > > > > The first one did not change a iota unfortunately. I'm about to > > spot the commit causing the loopback regression. It's a few patches > > before the first one you pointed. It's almost finished and I test > > your patch below immediately after. > > I bet you are going to find commit > 69b08f62e17439ee3d436faf0b9a7ca6fffb78db > (net: use bigger pages in __netdev_alloc_frag ) > > Am I wrong ?
Yes this time you guessed wrong :-) Well maybe it's participating to the issue. It's 0cf833ae (net: loopback: set default mtu to 64K). And I could reproduce it with 3.6 by setting loopback's MTU to 65536 by hand. The trick is that once the MTU has been set to this large a value, even when I set it back to 16kB the problem persists. Now I'm retrying your other patch to see if it brings the 10GE back to full speed. Willy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
