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: <20100824153920.63360072@s6510>
Date:	Tue, 24 Aug 2010 15:39:20 -0700
From:	Stephen Hemminger <shemminger@...tta.com>
To:	Ben Hutchings <bhutchings@...arflare.com>
Cc:	Marc Aurele La France <tsi@...berta.ca>,
	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

On Tue, 24 Aug 2010 23:20:41 +0100
Ben Hutchings <bhutchings@...arflare.com> wrote:

> On Tue, 2010-08-24 at 13:49 -0600, Marc Aurele La France wrote:
> > On Tue, 24 Aug 2010, Ben Hutchings wrote:
> > > On Tue, 2010-08-24 at 09:14 -0600, Marc Aurele La France wrote:
> > >> On Mon, 23 Aug 2010, Stephen Hemminger wrote:
> > >>> On Mon, 23 Aug 2010 08:44:37 -0600 (MDT)
> > >>> Marc Aurele La France <tsi@...berta.ca> wrote:
> > >>>> In regrouping for my next tack at this, I noticed that all stack traces go
> > >>>> through ip_append_data().  This would be ipv6_append_data() in the IPv6 case.
> > >>>> A _very_ rough draft that would have ip_append_data() temporarily drop down
> > >>>> to a smaller fake MTU follows ...
> > 
> > >>> Why doesn't NFS generate page size fragments?  Does Infiniband or your
> > >>> device not support this?  Any thing that requires higher order allocation
> > >>> is going to unstable under load.  Let's fix the cause not the apply bandaid
> > >>> solution to the symptom.
> > 
> > >> From what I can tell, IP fragmentation is done centrally.
> > > [...]
> > 
> > > Stephen and I are not talking about IP fragmentation, but about the
> > > ability to append 'fragments' to an skb rather than putting the entire
> > > packet payload in a linear buffer.  See
> > > <http://vger.kernel.org/~davem/skb_data.html>.
> > 
> > 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.
> 
> Not necessarily.  Offloading it to hardware, where possible, is usually
> a performance win.
> 
> > It is the "(or less)" part that I am working towards here.
> 
> The inability to allocate large linear buffers is not a good reason to
> generate packets smaller than the MTU.  You are working around the real
> problem.

IF NFS server is smart enough to generate:
   Header (skb) + one or more pages in fragment list
then IP fragmentation could do fragmentation by allocating
new headers skb (small) and assigning the same pages to
multiple skb's using page ref count.

It obviously isn't working that way.

The whole problem is moot because NFS over UDP has known data corruption
issues in the face of packet loss.  The sequence number of the IP fragment
can easily wrap around causing old data to be grouped with new data and
the UDP checksum is so weak that the resulting UDP packet will be consumed by the NFS
client ans passed to the user application as corrupted disk block.

DON'T USE NFS OVER UDP!




--
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/