From owner-freebsd-current Wed Apr 23 07:16:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA02015 for current-outgoing; Wed, 23 Apr 1997 07:16:18 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA02010 for ; Wed, 23 Apr 1997 07:16:16 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.5/8.8.5) id KAA17910; Wed, 23 Apr 1997 10:16:10 -0400 (EDT) Date: Wed, 23 Apr 1997 10:16:10 -0400 (EDT) From: Garrett Wollman Message-Id: <199704231416.KAA17910@khavrinen.lcs.mit.edu> To: Sujal Patel Cc: current@freebsd.org Subject: Possible networking bug in 2.2.1-Release In-Reply-To: References: Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk < said: > /* > * Verify that we have any chance at all of being able to queue > * the packet or packet fragments > */ > if ((ifp->if_snd.ifq_len + ip->ip_len / ifp->if_mtu + 1) >= > ifp->if_snd.ifq_maxlen) { > error = ENOBUFS; > goto bad; > } This code is bogus, but it is unlikely to be the problem that you are seeing. There are three things wrong with this code: 1) It has a slow divide. 2) Fragments are a case to worry about on the slow path. 3) It knows far too much about the drop-tail queueing strategy. (3) really bites, and when I implemented RED last year I tossed it completely. Unfortunately, my RED work has not made it into the main line of FreeBSD yet. I hope it will, some day, but it may take a while before I have an environment where I can test it again. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick