[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1282680572.2467.78.camel@edumazet-laptop>
Date: Tue, 24 Aug 2010 22:09:32 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: Marc Aurele La France <tsi@...berta.ca>
Cc: Ben Hutchings <bhutchings@...arflare.com>,
Stephen Hemminger <shemminger@...tta.com>,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
"David S. Miller" <davem@...emloft.net>,
Alexey Kuznetsov <kuznet@....inr.ac.ru>,
"Pekka Savola (ipv6)" <pekkas@...core.fi>,
James Morris <jmorris@...ei.org>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
Patrick McHardy <kaber@...sh.net>
Subject: Re: RFC: MTU for serving NFS on Infiniband
Le mardi 24 août 2010 à 13:49 -0600, Marc Aurele La France a écrit :
>
> Any payload has to either fit in the MTU, or has to be broken up into
> MTU-sized (or less) fragments, come hell or high water. That this is done
> centrally is a good thing. It is the "(or less)" part that I am working
> towards here.
>
Could you post a full stack trace, to help me understand the path from
NFS to ip_append_data ?
I suspect this is UDP transport ?
This reminds me a patch I wrote for IPV6 : We were allocating a huge
(MTU sized) buffer, just to fill few bytes in it...
commit 72e09ad107e78d69ff4d3b97a69f0aad2b77280f
Author: Eric Dumazet <eric.dumazet@...il.com>
Date: Sat Jun 5 03:03:30 2010 -0700
ipv6: avoid high order allocations
With mtu=9000, mld_newpack() use order-2 GFP_ATOMIC allocations, that
are very unreliable, on machines where PAGE_SIZE=4K
Limit allocated skbs to be at most one page. (order-0 allocations)
Signed-off-by: Eric Dumazet <eric.dumazet@...il.com>
Signed-off-by: David S. Miller <davem@...emloft.net>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists