Date: Mon, 19 Jun 2000 13:39:31 -0600 From: "Kenneth D. Merry" <ken@kdm.org> To: Jonathan Lemon <jlemon@flugsvamp.com> Cc: Alfred Perlstein <bright@wintelcom.net>, arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619133931.A79532@panzer.kdm.org> In-Reply-To: <20000619140029.D37084@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Mon, Jun 19, 2000 at 02:00:29PM -0500 References: <20000619111309.E26801@fw.wintelcom.net> <20000619140029.D37084@prism.flugsvamp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 19, 2000 at 14:00:29 -0500, Jonathan Lemon wrote: > On Mon, Jun 19, 2000 at 11:13:09AM -0700, Alfred Perlstein wrote: > > A whole bunch of people were a bit upset about kblob but haven't > > brought anything up that makes me not want to commit it. > > > > Now would be a good time to offer suggestions and critism before > > I bring it in. > > I think that this is a bad attitude, it sounds more like "I've > written this code, and want to bring it in no matter what other > people think". Before you even consider bringing the code in, > I think you need to address the points that have been brought up. > > The objections that I've seen (and agree with) are that the API > is not flexible enough to cope with different usage scenarios. > Creating a new API is not a small thing, and if we do that, then > it would be nice to make sure that it is flexible enough to > handle various things that we throw at it. The kblob API as > proposed below appears to be too special purpose. > > IIRC, Ken pointed you to some papers that address this issue. I > recall that the IOLite API was previously rejected for inclusion > for various reasons. I have also pointed you to an alternate API, > which is more flexible, while still providing the same functionality, > and can repost that here if need be. I would like to see something more generic as well, especially something that could work for both sending and receiving. 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. I think Jonathan's API is a little more generic than kblob, although I share some of Jonathan's reservations about using that much kva. 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. You could do similar things on receive. A receive side API could work well with something like RDMA. (Here's a URL: ftp://ftpeng.cisco.com/pub/rdma/draft-csapuntz-tcprdma-00.txt ) One problem is that allocating buffers in userland would work well for sends, but not as well for receives. So maybe both should be allowed? Anyway, those are just some ideas, I think there's some room for discussion here. > I think that any notion of committing this should be held off > until we have a chance to come to some kind of consensus on the > issue. Another point about the timeframe for deciding and committing both this and the accept filters -- a lot of people are away at Usenix, and last week a number of key developers were at the SMP gathering. (Some are going from one to the other, and therefore will have been away for more than a week.) I think we should hold off on this stuff until people have a chance to get back from Usenix and comment on it. I'll be heading to Usenix tomorrow, and if anyone would like to talk about this stuff in person, just let me know. 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?20000619133931.A79532>