From owner-freebsd-net Wed Feb 7 10:59:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id D710537B401 for ; Wed, 7 Feb 2001 10:59:06 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f17Ix6623446; Wed, 7 Feb 2001 10:59:06 -0800 (PST) Date: Wed, 7 Feb 2001 10:59:06 -0800 From: Alfred Perlstein To: Luigi Rizzo Cc: net@FreeBSD.ORG Subject: Re: send problem on udp socket... Message-ID: <20010207105906.O26076@fw.wintelcom.net> References: <20010207093731.N26076@fw.wintelcom.net> <200102071757.f17HvGu75581@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102071757.f17HvGu75581@iguana.aciri.org>; from rizzo@aciri.org on Wed, Feb 07, 2001 at 09:57:16AM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Luigi Rizzo [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. > > 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 - [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