From owner-freebsd-arch Mon Jun 19 14:45: 5 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-206-88-224.dsl.snfc21.pacbell.net [63.206.88.224]) by hub.freebsd.org (Postfix) with ESMTP id EE5D337B807; Mon, 19 Jun 2000 14:44:55 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id OAA09723; Mon, 19 Jun 2000 14:49:46 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200006192149.OAA09723@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Kenneth D. Merry" Cc: Mike Smith , arch@FreeBSD.ORG Subject: Re: kblob discussion. In-reply-to: Your message of "Mon, 19 Jun 2000 15:15:17 MDT." <20000619151517.A80732@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Jun 2000 14:49:46 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Mon, Jun 19, 2000 at 14:03:07 -0700, Mike Smith wrote: > > > > I think this entire discussion has gone just a little bit too far. > > I don't think so. You and Alfred seem to be convinced of the merits of > doing this in a specific (versus generic) manner, but Jonathan and I > obviously haven't been convinced. I didn't say "you think this conversation has gone too far" - your position is pretty obvious. I was simply stating mine, ok? > > The basic kblob architecture is sound, and does what most people are > > looking for in this context. IMO, it should probably be called > > socketblob, or something else equally boring, but that's neither here nor > > there. > > What are people planning on doing with this API? Is this intended as a web > server speedup of some sort? Yes. There's a niche for webservers that serve a relatively small quantity of static content, very rapidly. Think "small images". > You could have the same effect as kblob with a generic API. The kblob interface *is* a "generic API". It is in no way "specific" to this application. > > Some comments: > > > > > On Mon, Jun 19, 2000 at 13:09:11 -0700, Alfred Perlstein wrote: > > > > * Kenneth D. Merry [000619 12:40] wrote: > > > > > I would like to see something more generic as well, especially something > > > > > that could work for both sending and receiving. > > > > > > > > As would I. > > > > Receiving into a kernel-side buffer is somewhat pointless, really. You > > want stuff to go into userspace. This is an output accelerator, not a > > new I/O method. > > It isn't pointless at all. > > Again, you want a specific API, I'd rather see a generic API that could do > what kblob can, You haven't described any such generic API. Zero-copy user-space network I/O doesn't even begin to consider the issues that kblob addresses. > What I'm not sure of, though, is why we're proposing something that's quite > pointedly a narrow interface, when we could get much the same performance > out of a generic API, along with wider usability. Actually, in the target application, I wouldn't expect anything like the same sort of performance. With all the VM operations involved in the zero-copy API, it's well-suited to applications that generate dynamic content, but still rather more expensive for static content. > > One point that Alfred may have overlooked is that apart from the resource > > limit issues, kblob could be implemented entirely as a loadable syscall. > > (Then you could just compile the limit in, for slightly reduced > > flexibility.) This would address the "don't commit to a restricted API" > > issues while still getting the code out and used where it's needed. > > Again, can you elaborate on the uses of kblob? Is there code that uses it? Any service that, in response to a query, needs to send from a small collection of static data down a network socket. The common use is static content serving for http. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message