Date: Mon, 19 Jun 2000 14:49:46 -0700 From: Mike Smith <msmith@freebsd.org> To: "Kenneth D. Merry" <ken@kdm.org> Cc: Mike Smith <msmith@FreeBSD.ORG>, arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <200006192149.OAA09723@mass.osd.bsdi.com> In-Reply-To: Your message of "Mon, 19 Jun 2000 15:15:17 MDT." <20000619151517.A80732@panzer.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 <ken@kdm.org> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006192149.OAA09723>