* Luigi Rizzo <[EMAIL PROTECTED]> [010207 09:57] wrote:
>
> 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>
Oh, sorry, I'm pretty used to seeing the issue I _thought_ you
brought up so I instictively sent the pre-thought out message. :)
> 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.
Er, that I understand. But it's not that expected when you're
the only one writing/accepting. I guess defensive coding is
a good thing. :)
Since this is UDP, I'm not sure much should be done, perhaps
just document the return value, but honestly since it's _U_DP
it could just easily fail silently as long as local datagrams
are allowed to be lossy.
--
-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
