From owner-freebsd-arch Sat May 18 3:13:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id 7D9F037B40C; Sat, 18 May 2002 03:13:14 -0700 (PDT) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.6/8.11.6) id g4IACfe52918; Sat, 18 May 2002 12:12:41 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200205181012.g4IACfe52918@zibbi.icomtek.csir.co.za> Subject: Re: HEADS UP: ALTQ integration developer preview In-Reply-To: <3CE61675.BCE2A9E1@mindspring.com> from Terry Lambert at "May 18, 2002 01:53:09 am" To: tlambert2@mindspring.com (Terry Lambert) Date: Sat, 18 May 2002 12:12:41 +0200 (SAT) Cc: bra@fsn.hu (Attila Nagy), freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > 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