From owner-freebsd-net  Wed Feb  7  9:57:38 2001
Delivered-To: freebsd-net@freebsd.org
Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36])
	by hub.freebsd.org (Postfix) with ESMTP id B2E9D37B491
	for <net@FreeBSD.ORG>; Wed,  7 Feb 2001 09:57:20 -0800 (PST)
Received: (from rizzo@localhost)
	by iguana.aciri.org (8.11.1/8.11.1) id f17HvGu75581;
	Wed, 7 Feb 2001 09:57:16 -0800 (PST)
	(envelope-from rizzo)
From: Luigi Rizzo <rizzo@aciri.org>
Message-Id: <200102071757.f17HvGu75581@iguana.aciri.org>
Subject: Re: send problem on udp socket...
In-Reply-To: <20010207093731.N26076@fw.wintelcom.net> from Alfred Perlstein at "Feb 7, 2001  9:37:31 am"
To: bright@wintelcom.net (Alfred Perlstein)
Date: Wed, 7 Feb 2001 09:57:16 -0800 (PST)
Cc: rizzo@aciri.org, net@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

> > When you attempt to send() to an udp socket, the socket buffer
> > (which has no function other than bounding the max message size
> > for UDP sockets) is just bypassed, and the low-level routine gets
> > called. The latter (typically ip_output() or ether_output()) can
> > return an ENOBUFS message if some queue fills up down there (typically
> > the interface queue), and the error message is passed up.
...

> ENOBUFS == ESYSADMINNEEDSTORAISENMBCLUSTERS
> 
> Sorry, basically you shouldn't see ENOBUFS unless you're doing
> something wrong, running a box that isn't set up to handle the
> amount of traffic you want to push through it.

not really. The problem is not running out of mbufs, is that the
interface queue (usually limited to net.inet.ip.intr_queue_maxlen)
fills up, and this has nothing to do with NMBCLUSTERS. This used
not to be a problem in the past precisely because boxes were slower
than ethernet cards.

And trying to push through a device more than it can handle
happens all the time with disks, and it is the reason why
you want to have blocking behaviour.

<proposed solution skipped because it seems to deal with mbuf
 exhaustion whereas the problem is elsewhere>

Re. the race that you mention below, again it happens all
the times -- select tells you can do X, then someone else
is faster and your X syscall fails. See the case of multiple
servers trying to accept() on a socket.

	cheers
	luigi

> The problem here, is that you still have a race, you can return
> "ready to send" but yet another subsystem decideds to chew mbufs
> before you get to restart your call.  I guess we have to document
> that as well, but is it allowable via any spec out there?
> "_maybe_ ready for more data"  ie. select() return ok, but write
> return not ok?
> 
> -- 
> -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
> "I have the heart of a child; I keep it in a jar on my desk."
> 



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