Date: Mon, 19 Jun 2000 14:03:07 -0700 From: Mike Smith <msmith@freebsd.org> To: "Kenneth D. Merry" <ken@kdm.org> Cc: arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <200006192103.OAA09596@mass.osd.bsdi.com> In-Reply-To: Your message of "Mon, 19 Jun 2000 14:34:37 MDT." <20000619143437.A80133@panzer.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I think this entire discussion has gone just a little bit too far. 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. 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. > > > Another thing that I would like to see is the ability to get notification > > > of when the I/O is done, like async I/O. > > > > That can be easily put into kblob at the expense of some performance, > > however it would require a side allocation per send which negates > > the whole purpose of it as a low overhead extremely fast way to send > > data. > > This gets into the generic API versus specific API issue. It would be fairly trivial to add a mechanism for generating kevents when points in the socket transmit buffer are reached, which would then allow you to do this. I don't think that it should be added to the kblob code as a specific hack, however. > > > I'd almost like the ability to allocate the buffers in userland, and then > > > map them into the kernel and revoke the userland mapping, so the user > > > process can't get to it while you're doing a send. > > > > So use sendfile. :) > > That only works for files. :) Since the goal here is to copy the object once into the kernel, and then never move it across the userspace:kernel boundary again, the map/unmap proposal seems just a little bit silly, really. It's a complex optimisation entirely off the critical path, and fails to consider the problems that kblob is actually trying to address. > Anyway, what I'm getting at is you could use something like RDMA to DMA > data from the NIC directly into user-supplied buffers. This has little or nothing to do with kblob. > > > Anyway, those are just some ideas, I think there's some room for > > > discussion here. > > > > I'd rather not, I've already discussed it a lot and many people > > want this functionality. The people that want more flexibility > > don't realize that the interface is easily extendable (or don't > > want to extend it themselves), and the people that don't like it > > on principle don't see the need for changes to get real world > > performance increases. > > 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. 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. -- \\ 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?200006192103.OAA09596>