Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 28 Jul 2000 14:34:48 -0700 (PDT)
From:      Archie Cobbs <archie@whistle.com>
To:        Mike Silbersack <silby@silby.com>
Cc:        freebsd-net@FreeBSD.ORG, jlemon@FreeBSD.ORG
Subject:   Re: sub-optimal tcp_ouput() performance in the face of ENOBUFS
Message-ID:  <200007282134.OAA27448@bubba.whistle.com>
In-Reply-To: <Pine.BSF.4.21.0007272130290.16889-100000@achilles.silby.com> from Mike Silbersack at "Jul 27, 2000 09:35:57 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
Mike Silbersack writes:
> > 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.

OK, now I'm trying to understand the code.. uh.. ok.. now looking
at this commit..

> 1.43 Fri Jun 2 17:38:45 2000 UTC by jlemon 
> 
> When attempting to transmit a packet, if the system fails to allocate
> a mbuf, it may return without setting any timers.  If no more data is
> scheduled to be transmitted (this was a FIN) the system will sit in
> LAST_ACK state forever.
> 
> Thus, when mbuf allocation fails, set the retransmit timer if neither
> the retransmit or persist timer is already pending.

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()..

It seems like this commit should have been added after the call
to ip_output(), no matter what "error" is equal to..

Clarifications warmly accepted..

Thanks,
-Archie

___________________________________________________________________________
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com


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?200007282134.OAA27448>