gigabit ethernet, nfsroot, jumbo packets, questions, and bugs (2.6.0-test9)

From: Tupshin Harper (tupshin_at_tupshin.com)
Date: 11/14/03

  • Next message: Nick Piggin: "Re: Nick's scheduler v18"
    Date:	Thu, 13 Nov 2003 21:35:28 -0800
    To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
    
    

    I'm trying to set up a diskless testbed using gigabit ethernet, and I'm
    running into a few issues. First, the scenario:

    One client, and one server each with an smc EZCard 1000.
    Kernel 2.6.0-test9 with the sk98lin driver on both sides
    Client has kernel compiled with sk98lin built in, and nfsroot and dhcp
    autoconfig built in.
    Client is getting bootstrapped off a hard drive (for now, since
    etherboot doesn't support the driver yet) with grub loading the nfsroot
    kernel from disk, and then mounting nfsroot by adding root=/dev/nfs

    What works:
    Everything basic.

    What doesn't:
    Above scenario with Jumbo packets (MTU = 9000 or anything above 1500)

    For performance reasons, I'm wanting to use large packets(the switch
    between the devices supports it, and jumbo packet communication works
    fine in the non-diskless scenario).

    Questions:
    1) Is there a good way to set the MTU of the client via dhcp or by
    passing a parameter to the kernel?

    2) If server is set to 9000 MTU and client is set to 1500 MTU, should
    complete failure ensue(e.g. nfs times out indefinitely), or should some
    autonegotiation take place? If there should be autonegotiation, then it
    isn't working.

    Definite Bug:
    If the server is set to 9000 MTU, ifconfig down, and ifconfig up with
    default MTU doesn't work. Ifconfig then claims that the card is set to
    1500 MTU, but it is unable to communicate with the client until module
    is unloaded and reloaded, even though MTU is an ifconfig parameter and
    not a module parameter. I'm presuming that MTU has not actually been set
    back to 1500, but I don't know of an easy way to tell if that's the case
    when ifconfig appears to be lying to me.

    -Thanks
    -Tupshin

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Nick Piggin: "Re: Nick's scheduler v18"

    Relevant Pages

    • OpenVPN und MTU
      ... wenn ich sowohl auf dem Server als ... auch auf dem Client die MTU des tun0 manuell auf 1387 Bytes oder kleiner ... über die der Tunnel aufgebaut wird. ... dass Path MTU Discovery nicht korrekt funktioniert? ...
      (de.comp.os.unix.networking.misc)
    • Re: Multi-BSS problem with Atheros 5212
      ... flags=8843metric 0 mtu 2290 ... ath0: using obsoleted if_watchdog interface ... # ifconfig ath0 scan | grep wlan ... The client is only able to associate with wlan1, ...
      (freebsd-net)
    • Re: Slow gateway performance under load
      ... server# ifconfig -a ... ste0: flags=8843mtu 1500 ... > MGJC> Then the internet is really really slow.. ... > ifconfig -a ...
      (comp.unix.bsd.freebsd.misc)
    • Re: Fragmented Internet Connection
      ... MTU adjustments may well be the answer to your problem. ... your client machines work OK when connected directly to the modem, ... as they pass through the software router created on the server. ...
      (microsoft.public.windows.server.networking)
    • Re: Ssh connection hangs. Ignored ACK packet?
      ... the server to the client, scp transfers a few Kbytes and then says ... or problems with MTU discovery. ... the client is an AMD Duron connected to ...
      (Debian-User)

    Loading