Date: Sat, 18 May 2002 12:12:41 +0200 (SAT) From: John Hay <jhay@icomtek.csir.co.za> To: tlambert2@mindspring.com (Terry Lambert) Cc: bra@fsn.hu (Attila Nagy), freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: HEADS UP: ALTQ integration developer preview Message-ID: <200205181012.g4IACfe52918@zibbi.icomtek.csir.co.za> In-Reply-To: <3CE61675.BCE2A9E1@mindspring.com> from Terry Lambert at "May 18, 2002 01:53:09 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> Attila Nagy wrote: > > > > the "em" driver (if "gx" is already in the initial plan), because it > > > > reportedly works better (for example I couldn't do NFS serving with UDP > > > > packets bigger than the MTU with that, while the "em" driver works OK). > > > > > > It *does* frag packets bigger than the MTU, right? > > > > netstat didn't show any errors regarding to that. If I used an NFS > > readsize, smaller than the 1500 bytes MTU it worked (was slow, but > > worked). > > netstat's frag counters were increased. > > I couldn't use tcpdump (I had no bpf support) to see what happens on the > > wire... > > Sending datagrams bigger than the MTU is a bad idea. > > I would be real tempted to drop the packets and send "don't fragment" > ICMP responses to beat up anyone who abused UDP by sending larger > than the MTU. > > I guess this is about Linux UDP NFS clients, in particular. If this is the same "problem" nfs had all the years, then nobody is violating the MTU. What was happening is this: NFS sends a big packet (for efficiency) and that gets fragmented by the ip layer and then sent as so many back to back packets. If the card on the receiving could not receive so many back to back packets and looses one or more, nfs will get stuck retrying the same big packet and the same thing happening over and over. John -- John Hay -- John.Hay@icomtek.csir.co.za / jhay@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200205181012.g4IACfe52918>