Date: Fri, 28 Jul 2000 21:58:05 -0500 (CDT) From: Mike Silbersack <silby@silby.com> To: Archie Cobbs <archie@whistle.com> Cc: freebsd-net@FreeBSD.ORG, jlemon@FreeBSD.ORG Subject: Re: sub-optimal tcp_ouput() performance in the face of ENOBUFS Message-ID: <Pine.BSF.4.21.0007282056360.20134-100000@achilles.silby.com> In-Reply-To: <200007282134.OAA27448@bubba.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0007282056360.20134-100000>