Date: Mon, 19 Jun 2000 12:53:45 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Jonathan Lemon <jlemon@flugsvamp.com> Cc: arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619125345.H26801@fw.wintelcom.net> 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
* Jonathan Lemon <jlemon@flugsvamp.com> [000619 11:55] 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. If my email seemed a bit impatient and harsh, that was my intention. I have no desire deal with another accept filter mess because I can't provoke a repsonse until I actually commit the code. > 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. I don't want the overhead of a complex API, I want something simple, if someone later wants to expand on kblob and not break its performance I won't stand in the way. I'd like to see a way to "recycle" and chain kblobs together in the future, but that's not going to happen today. There's nothing wrong with the current kblob implementation that makes it unflexible, it's just that the flexible hooks aren't in place yet because I can't think of any. In fact, I'd happily take someone else's kblob implementation, the only problem is that I've been waiting nearly 9 months for one and nothing has popped up. > 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. Yes, please do. > 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. I really would rather stay away from something so complex that the overhead of usage causes problems, the whole idea behind kblob is _just_ pre-loading data into the kernel so you can send it. If i wanted to do IO-lite I'd be using sendfile(). I don't want to propose some giant api, and I have no desire to work on one and put it up for scrutinty so it can be knit-picked to death, I just don't have the time. If something as complex as IO-Lite was rejected then it just goes to show you how you can't please all of the people all of the time. I'm also really getting annoyed that people are complaining about performance "hacks", we _need_ "hacks" like sendfile and kblob to do zero copy. I'm getting so discouraged over here that just keeping my changes private would really be a lot simpler. The only unfortunate effect is that the users never get the same advantages I will, then again I could just commit it because it's what we need. It doesn't bother you at all that cdrom.com can push 100mbit and support 6000 users on FreeBSD but Joe Average FreeBSD User can't because the hacks used aren't available? -- -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?20000619125345.H26801>