From owner-freebsd-chat Wed Oct 25 8:27:26 2000 Delivered-To: freebsd-chat@freebsd.org Received: from oof.netnation.com (040imtd196.chartermi.net [24.247.40.196]) by hub.freebsd.org (Postfix) with ESMTP id CA5D037B479 for ; Wed, 25 Oct 2000 08:27:23 -0700 (PDT) Received: from sim by oof.netnation.com with local (Exim 3.16 #1 (Debian)) id 13oSSL-0000P4-00; Wed, 25 Oct 2000 11:27:09 -0400 Date: Wed, 25 Oct 2000 11:27:09 -0400 From: Simon Kirby To: Jonathan Lemon Cc: Dan Kegel , chat@freebsd.org, linux-kernel@vger.kernel.org Subject: Re: kqueue microbenchmark results Message-ID: <20001025112709.A1500@stormix.com> References: <20001024225637.A54554@prism.flugsvamp.com> <39F6655A.353FD236@alumni.caltech.edu> <20001025010246.B57913@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001025010246.B57913@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Wed, Oct 25, 2000 at 01:02:46AM -0500 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Oct 25, 2000 at 01:02:46AM -0500, Jonathan Lemon wrote: > Yes, someone pointed me to those today. I would suggest reading > some of the relevant literature before embarking on a design. My > paper discusses some of the issues, and Mogul/Banga make some good > points too. > > While an 'edge-trigger' design is indeed simpler, I feel that it > ends up making the job of the application harder. A simple example > to illustrate the point: what if the application does not choose > to read all the data from an incoming packet? The app now has to > implement its own state mechanism to remember that there may be pending > data in the buffer, since it will not get another event notification > unless another packet arrives. What applications would do better by postponing some of the reading? I can't think of any reason off the top of my head why an application wouldn't want to read everything it can. Doing everything in smaller chunks would increase overhead (but maybe reduce latencies very slightly -- albeit probably not much when using a get_events()-style interface). Isn't it probably better to keep the kernel implementation as efficient as possible so that the majority of applications which will read (and write) all data possible can do it as efficiently as possible? Queueing up the events, even as they are in the form received from the kernel, is pretty simple for a userspace program to do, and I think it's the best place for it. I know nothing about any other implementations, though, and I'm speaking mainly from the experiences I've had with coding daemons using select(). You mention you wrote a paper discussing this issue...Where could I find this? Simon- [ Stormix Technologies Inc. ][ NetNation Communications Inc. ] [ sim@stormix.com ][ sim@netnation.com ] [ Opinions expressed are not necessarily those of my employers. ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message