From owner-freebsd-arch Tue Dec 5 13:23:34 2000 From owner-freebsd-arch@FreeBSD.ORG Tue Dec 5 13:23:31 2000 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mail.wgate.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id A518237B400 for ; Tue, 5 Dec 2000 13:23:30 -0800 (PST) Received: from jesup.eng.tvol.net ([10.32.2.26]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id Y2Q95H02; Tue, 5 Dec 2000 16:23:34 -0500 Reply-To: Randell Jesup To: Alfred Perlstein Cc: Terry Lambert , Bosko Milekic , arch@FreeBSD.ORG Subject: Re: zero copy code review References: <200012042352.QAA12392@usr02.primenet.com> <20001204162015.A8051@fw.wintelcom.net> <20001204162659.B8051@fw.wintelcom.net> From: Randell Jesup Date: 05 Dec 2000 16:30:26 -0500 In-Reply-To: Alfred Perlstein's message of "Mon, 4 Dec 2000 16:26:59 -0800" Message-ID: User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein writes: >> Well behaved applications (read: written by me) deal with errors >> like ENOBUFS properly, what they do is close the socket and >> commence throttling connections. Most user-level applications do not. Certainly most applications that call write() don't. In fact, a grep of /usr/src shows that of things outside of sys, only a handful test for ENOBUFS: telnet, sendmail, ipfilter, ntp, natd, and ping seem to include a test (I didn't check what they do with it though). >> I would not want my process to be stuck in the kernel waiting >> for bufferspace that could take quite a long time get ahold of. In many cases you do. How different is that than waiting on some other resource that may take a long time, or getting a response to a write or read across a network? In fact, I'd assert in most cases waiting is the appropriate action unless a call is non-blocking. Given the very small number of programs that _do_ handle ENOBUFS, I'd assert that the default action should be to wait, unless the application has said it wants to hear about them. >> However I can understand someone wanting a niave process not >> to get such errors because they may misbehave and do stupid >> things like busy loop or just abort entirely. or fail a complex transaction, etc. Like 99% of user code out there when faced with ENOBUFS. >> Perhaps adding a per-process or per-socket or per-something flag >> to ask for indefinite blocking (or turn it off) would be a good >> idea, honestly having it one way or the other isn't very good >> depending on your application. I can live with the current >> situation so I'll leave 'fixing' this to someone who wants >> the indefinite blocking. per-socket makes sense; or keyed off non-blocking mode. The default should be wait. >> Oh, and don't forget, you can't block me indefinitely if I'm >> writing to a non-blocking socket. In fact if M_WAIT is set >> I shouldn't be blocking at all on a non-blocking socket. Agreed; even more reason to tie it to non-blocking mode. >One more thing, ENOBUFS is indicative of a misconfiguration and >shouldn't happen in day to day operations, if it does happen then >the user needs to reconfigure for more buffer space. Or it's indicative of a DoS attack (possibly unintentional), or a load problem, possibly temporary. I dislike arbitrary tuning parameters. Generally they're either ignored (mostly), or set wildly high in the hope of the annoyance someone hit once going away. Or just set randomly. Most of the people doing the setting don't have a good grasp of why it should be set to a specific value. Kind of like putting a spark-advance knob on the steering wheel (which they once did, believe it or not). -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message