From owner-freebsd-net Thu Jul 27 19:36: 0 2000 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with SMTP id 1D26437B55E for ; Thu, 27 Jul 2000 19:35:58 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 16898 invoked by uid 1000); 28 Jul 2000 02:35:57 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 28 Jul 2000 02:35:57 -0000 Date: Thu, 27 Jul 2000 21:35:57 -0500 (CDT) From: Mike Silbersack To: Archie Cobbs Cc: freebsd-net@freebsd.org Subject: Re: sub-optimal tcp_ouput() performance in the face of ENOBUFS In-Reply-To: <200007272138.OAA11016@bubba.whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 27 Jul 2000, Archie Cobbs wrote: > Dear TCP gurus, > > It seems like there is sub-optimal behaviour in tcp_output(), > and I'm wondering what other people think. > > Consider an output interface whose transmit queue is full. > tcp_output() calls ip_output(), and it will return ENOBUFS. > Here's where this is handled (tcp_output, line 863): I get the impression that ENOBUFS was never tested, if it makes you feel any better. The code which checks to make sure a timer is pending wasn't even there until a few weeks ago. Until it was added, sockets could semi-easily get stuck in the LAST_ACK state forever. So, while you're fixing the case you just found, you may want to try to think of other bad outcomes due to ENOBUFS - there probably are a few more. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message