From owner-freebsd-net Fri Jul 28 19:58:11 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 5B28537B8EB for ; Fri, 28 Jul 2000 19:58:08 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 20284 invoked by uid 1000); 29 Jul 2000 02:58:05 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 29 Jul 2000 02:58:05 -0000 Date: Fri, 28 Jul 2000 21:58:05 -0500 (CDT) From: Mike Silbersack To: Archie Cobbs Cc: freebsd-net@FreeBSD.ORG, jlemon@FreeBSD.ORG Subject: Re: sub-optimal tcp_ouput() performance in the face of ENOBUFS In-Reply-To: <200007282134.OAA27448@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 Fri, 28 Jul 2000, Archie Cobbs wrote: > I understand the scenario described by the commit message. What > I don't understand about this commit is this: suppose the exact > same scenario happens, except that instead of ip_output() returning > ENOBUFS, it returns zero, BUT the packet is dropped anyway because > of (say) an Ethernet collision. > > Then why wouldn't you have the same thing happen, i.e., no retransmit > timer running and you're stuck in LAST_ACK forever? No timer is being > set in the subsequent code at the end of tcp_output().. Hm, I was going to wager that some calling procedure was acting differently depending on the return value of tcp_output, but since ENOBUFS returns 0, and the error isn't checked anyway. It may be that a timer is active in the normal case, causing the timer check in the ENOBUFS case to be unneccesary normally... that still doesn't explain all cases, though. Hmph. I think a really good patch is going to take a lot of research. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message