Date: Wed, 7 Feb 2001 09:57:16 -0800 (PST) From: Luigi Rizzo <rizzo@aciri.org> To: bright@wintelcom.net (Alfred Perlstein) Cc: rizzo@aciri.org, net@FreeBSD.ORG Subject: Re: send problem on udp socket... Message-ID: <200102071757.f17HvGu75581@iguana.aciri.org> In-Reply-To: <20010207093731.N26076@fw.wintelcom.net> from Alfred Perlstein at "Feb 7, 2001 9:37:31 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102071757.f17HvGu75581>