From: manio <manio@skyboo.net>
To: unlisted-recipients:; (no To-header on input)
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH 2.6.21.1] nfs-root: added possibility to override default MTU (for UDP jumbo frames)
Date: Mon, 02 Jul 2007 18:27:44 +0200 [thread overview]
Message-ID: <46892780.5060703@skyboo.net> (raw)
In-Reply-To: <4688FA00.5050801@redhat.com>
Peter Staubach wrote:
> manio@skyboo.net wrote:
>> To use a NFS-root for UDP jumbo frames the kernel on the client need
>> to bring
>> up interface with MTU set to 9000 bytes - otherwise it cannot contact
>> server
>> with jumbo frames enabled (nfs server not responding, still trying)
>> and cannot
>> boot. Added a kernel parameter named 'ipmtu' which can be used to
>> specify
>> initial MTU size when booting via nfsroot.
>>
>>
>
> Could you describe the problem better, please? Something does not
> sound right. Both ends need to have jumbo frames enabled in order
> to use jumbo frames, but if one end or the other does not, the systems
> still should be able to exchange packets using normal sized ethernet
> packets. Isn't this a problem that mtu discovery should handle?
>
> Thanx...
>
> ps
ok - first of all: yes you're right - if both ends have jumbo frames
enabled
it is all working fine - the patch is just for enabling client's MTU to
jumbo
because when booting via NFS-root client's MTU is set to default (1500
in ethernet case). I know that when server has MTU=9000 and client=1500
it should work - but it only work when nfs-root directory is mounted with
TCP protocol. But i mean using UDP frames (then nfs options: wsize and
rsize could be 8192 bytes).
If I'm not clear I'll give you simple example:
My server has jumbo frames enabled (it's not a problem to set it because
server has HDD - can set up MTU during run time).
The problem is when my diskless client need to boot via nfs-root.
With vanilla kernel it looks like this:
1. Client boots
2. PXE get address from DHCP
3. without problem PXE client get kernel from server (via tftpboot)
4. it stop when kernel is going to mount root filesystem from NFS
it still trying because server has jumbo enabled and client doesn't
(endless message: NFS server is not responding, still trying)
If I pass the ipmtu option with 9000 value to client's patched kernel then
all is working fine because both client and server has jumbo frames
enabled and client is able to mount root filesystem via NFS from server.
the problem was some time ago posted by Tupshin Harper:
http://www.ussg.iu.edu/hypermail/linux/kernel/0311.1/1055.html
... and is also described on my webpage:
http://manio.skyboo.net/nfsroot_jumbo/
i hope you know what's going on :)
best regards,
Mariusz Bialonczyk
next prev parent reply other threads:[~2007-07-02 16:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-02 12:38 [PATCH 2.6.21.1] nfs-root: added possibility to override default MTU (for UDP jumbo frames) manio
2007-07-02 13:13 ` Peter Staubach
2007-07-02 16:27 ` manio [this message]
2007-07-02 14:09 ` Krzysztof Halasa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46892780.5060703@skyboo.net \
--to=manio@skyboo.net \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).