linux-kernel - Re: RFC: MTU for serving NFS on Infiniband

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/