> > 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 - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
> "I have the heart of a child; I keep it in a jar on my desk."
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
