netdev - 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: <1282688441.22839.34.camel@localhost>
Date:	Tue, 24 Aug 2010 23:20:41 +0100
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Marc Aurele La France <tsi@...berta.ca>
Cc:	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

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.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

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