Date: Mon, 19 Jun 2000 13:09:11 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: "Kenneth D. Merry" <ken@kdm.org> Cc: Jonathan Lemon <jlemon@flugsvamp.com>, arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619130911.I26801@fw.wintelcom.net> In-Reply-To: <20000619133931.A79532@panzer.kdm.org>; from ken@kdm.org on Mon, Jun 19, 2000 at 01:39:31PM -0600 References: <20000619111309.E26801@fw.wintelcom.net> <20000619140029.D37084@prism.flugsvamp.com> <20000619133931.A79532@panzer.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* Kenneth D. Merry <ken@kdm.org> [000619 12:40] wrote: > 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. As would I. > 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. > 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 haven't seen Johnathan's API. > 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. :) > 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 > ) You've got to be kidding if you think I'm going to draft an RFC to add bits to the TCP header. > 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? Er.. What's the point of a many to one mapping for a recieve buffer? The only way to do this would be to allow the kernel's mbuf map to be map'd in by a user process, which doesn't make much sense. > 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 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 was there, many people liked the ideas I'm presenting. > 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. I'll be there as well. Have some code handy that implememnts this and we'll discuss it, if not just grabbing a beer would be fun. :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." 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?20000619130911.I26801>