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: <alpine.WNT.2.00.1008240856170.2000@cluij.ucs.ualberta.ca>
Date:	Tue, 24 Aug 2010 09:14:54 -0600 (Mountain Daylight Time)
From:	Marc Aurele La France <tsi@...berta.ca>
To:	Stephen Hemminger <shemminger@...tta.com>
cc:	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 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.

The MTU is a device attribute, yes.  But, here, it is ip_append_data(), 
not NFS nor the device driver, whose responsibility it is to break up the 
payload into fragments, either by itself or using any facility supported 
by the adapter.  What I'm saying is that there's no reason to require all 
fragments, except the last, to be MTU-sized.  The RFCs I've looked at 
allow them to be shorter which can be used to advantage when MTU-sized 
fragments cannot be allocated in a memory fragmentation scenario, instead 
of reporting an error.

Marc.

+----------------------------------+----------------------------------+
|  Marc Aurele La France           |  work:   1-780-492-9310          |
|  Academic Information and        |  fax:    1-780-492-1729          |
|    Communications Technologies   |  email:  tsi@...berta.ca         |
|  352 General Services Building   +----------------------------------+
|  University of Alberta           |                                  |
|  Edmonton, Alberta               |    Standard disclaimers apply    |
|  T6G 2H1                         |                                  |
|  CANADA                          |                                  |
+----------------------------------+----------------------------------+
--
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/