Date: Mon, 19 Jun 2000 14:56:47 -0700 From: Mike Smith <msmith@freebsd.org> To: Jonathan Lemon <jlemon@flugsvamp.com> Cc: arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <200006192156.OAA09767@mass.osd.bsdi.com> In-Reply-To: Your message of "Mon, 19 Jun 2000 16:43:29 CDT." <20000619164329.F37084@prism.flugsvamp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Mon, Jun 19, 2000 at 02:03:07PM -0700, Mike Smith wrote: > > > 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. > > *cough*. Are you sure about that? An output accelerator is a new I/O > method regardless of what you want to call it. *sigh* Kblob is not a new output method. It's a bolt-on to the 'write' interface, as opposed to, say, zero-copy I/O. > And for a lot of cases > you don't need stuff to actually go to user space. In many situations, > you will receive data, perform operations on a very small part of it, > and then send the data elsewhere, whether to disk or network. However, for a user-space application to do this, you want it to come out to user-space, right? Irregardless, this is irrelevant in this context. > Kblob only addresses part of the problem. Kblob addresses exactly one problem, and does it in an expedient fashion. > Also, if I want to send data from disk -> network, with the kblob > API, I essentially have the following sequence of calls: > > read(fd, address, length) > kblob(address, length) > kblobsend(...) > > which is to say, the data is copied from > disk -> userspace (assuming direct I/O) > userspace -> kernel, > kernel -> network. > > Why shouldn't I be able to bypass second copy entirely and do: > disk -> kernel (data now in kernel 'blob') > kernel -> network Because this isn't what you use kblob for. That's what you use sendfile for. The entire use of the kblob API is: user -> kernel kernel -> network kernel -> network kernel -> network kernel -> network kernel -> network kernel -> network kernel -> network etc., > Again, this is not addressed in the kblob API. Don't throw sendfile() > up as an example, because I want the data to be kept in the kernel > after being read from disk. It is. You remember that thing called the buffer cache? > > > I'd be more in favor of doing it right the first time, rather than > > > continually revising and extending the interface. > > > > As it stands, kblob is "right". It's lean and to-the-point. I'd rather > > not see it undergo second-system syndrome before it's even made it to > > first base. If you plan to implement an efficient zero-copy network I/O > > interface, then it should be done from scratch, not as a wart on the side > > of what is really fairly specific feature. > > I disagree on your definition of "right". I would argue that if we're > going to implement an I/O accelerator of any form, it should not be so > specific purpose that it precludes any other possible applications. > > - How do I receive data _into_ a kblob (either from a network or a disk?) You don't. It's not relevant to this application. > - Once data is in a kblob, is there any possibility of editing it? > Do I have to throw it all away and reload if I want to make a minor > change to the data? It's static content. > - Can I retrieve data from a kblob? No. The kblob is a send-only acceleration buffer. > - Can kblobs be transferred to disk? No. Since the data in a kblob came from userspace, and can't be modified in the kernel, this would be pointless. Again, folks; kblob is an optimisation for a very common performance case, not a network engineer's wet dream. It's meant to address a real-world problem in an efficient fashion. If you have a Grand Plan for something else, that's great - I'd recommend you keep working on it. In the meantime, there are a lot of people that can do a lot of useful things with kblob as-is, and knocking it down just because it's not _your_ idea of the Perfect In-Kernel Network Container Object is kinda silly. -- \\ 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?200006192156.OAA09767>