Date: Mon, 19 Jun 2000 15:15:17 -0600 From: "Kenneth D. Merry" <ken@kdm.org> To: Mike Smith <msmith@FreeBSD.ORG> Cc: arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619151517.A80732@panzer.kdm.org> In-Reply-To: <200006192103.OAA09596@mass.osd.bsdi.com>; from msmith@FreeBSD.ORG on Mon, Jun 19, 2000 at 02:03:07PM -0700 References: <20000619143437.A80133@panzer.kdm.org> <200006192103.OAA09596@mass.osd.bsdi.com>
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. > 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? You could have the same effect as kblob with a generic API. > 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, > > > > 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. Of course not, it has to do with a more generic API for doing zero copy with packaged message blocks. > > > > 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. I agree that a zero copy API should be done right from scratch. 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. It might help a bit if y'all would explain the intended use for kblob, and why it has to go into the tree ASAP. > 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? Ken -- Kenneth Merry ken@kdm.org 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?20000619151517.A80732>