From owner-freebsd-hackers  Sat Jul 31  1:28:14 1999
Delivered-To: freebsd-hackers@freebsd.org
Received: from ns.oeno.com (ns.oeno.com [194.100.99.145])
	by hub.freebsd.org (Postfix) with SMTP id 7F15014D32
	for <hackers@FreeBSD.ORG>; Sat, 31 Jul 1999 01:28:09 -0700 (PDT)
	(envelope-from will@ns.oeno.com)
Received: (qmail 7420 invoked by uid 1001); 31 Jul 1999 08:24:51 -0000
Date: 31 Jul 1999 08:24:50 -0000
Message-ID: <19990731082450.7417.qmail@ns.oeno.com>
From: Ville-Pertti Keinonen <will@iki.fi>
To: dillon@apollo.backplane.com
Cc: wes@softweyr.com, hackers@FreeBSD.ORG
In-reply-to: <199907301634.JAA91238@apollo.backplane.com> (message from
	Matthew Dillon on Fri, 30 Jul 1999 09:34:46 -0700 (PDT))
Subject: Re: Documenting writev(2) ENOBUFS error
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


> :wes@softweyr.com (Wes Peters) writes:
> :
> :>      [ENOBUFS]     Insufficient system buffer space exists to complete the op-
> :>                    eration.
> :
> :Do you know what kind of circumstances that error *really* occurs
> :under?
> :
> :If it happened with files, that would be a bug and should be fixed.
> :The call is supposed to block to wait for writes to be possible.  This
> 
>     I am almost certain that this error can only occur when writing to
>     sockets, and only then of the network mbuf pool is completely exhausted.
>     UDP is probably the most vulernable.

It looks to me like it can't happen to stream sockets using
write/writev.

As far as I can tell, the ENOBUFS error can occur internally for sends
if:

    - There is a shortage of mbufs at a low level (at higher levels,
    code either blocks or panics)
    - A network interface has a lot of packets queued (this is done at
    an IP level)
    - The socket buffer of a local datagram socket is full (the receiving
    socket, not the one the send occurred on)

The TCP layer doesn't let ENOBUFS from low-level calls get through,
but returns success. A TCP socket is prepared to resend the data at a
higher level, anyhow, so the data is not lost and an error doesn't
need to be returned.

OOB data or implicit connections can return ENOBUFS for TCP sends, but
they are activated by parameters only available through the
send/sendto API.

So you can get ENOBUFS not related to mbufs for UDP/local datagram
sockets, but you should never get ENOBUFS from write for TCP sockets
or local stream sockets.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message