Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755583Ab0HXUKE (ORCPT ); Tue, 24 Aug 2010 16:10:04 -0400 Received: from mail-ww0-f42.google.com ([74.125.82.42]:51067 "EHLO mail-ww0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755094Ab0HXUKB (ORCPT ); Tue, 24 Aug 2010 16:10:01 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=UXSZ/wxtteVTfBH0L5eHba1VEOPpLcdbfu57tLOAYYvEWt3mTzoHLLgBXc1Z+wWM53 7/u0URuX8vBqQQI5zx8RWIkJzBWeqYEs+IgbxRO3TtHLm3kUZeAkCB6yCZOx8vuEd1nc Dh0aWj+p/aAwq9/Rr4IANSY+QJLtKsZZAReiE= Subject: Re: RFC: MTU for serving NFS on Infiniband From: Eric Dumazet To: Marc Aurele La France Cc: Ben Hutchings , Stephen Hemminger , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, "David S. Miller" , Alexey Kuznetsov , "Pekka Savola (ipv6)" , James Morris , Hideaki YOSHIFUJI , Patrick McHardy In-Reply-To: References: <20100823080543.319143e3@nehalam> <1282672647.2302.15.camel@achroite.uk.solarflarecom.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 24 Aug 2010 22:09:32 +0200 Message-ID: <1282680572.2467.78.camel@edumazet-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1326 Lines: 38 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 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 Signed-off-by: David S. Miller -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/