Date: Mon, 19 Jun 2000 17:58:05 -0500 From: Jonathan Lemon <jlemon@flugsvamp.com> To: Alfred Perlstein <bright@wintelcom.net> Cc: Jonathan Lemon <jlemon@flugsvamp.com>, Mike Smith <msmith@FreeBSD.ORG>, arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619175805.J37084@prism.flugsvamp.com> In-Reply-To: <20000619153325.D17420@fw.wintelcom.net> References: <20000619164329.F37084@prism.flugsvamp.com> <200006192156.OAA09767@mass.osd.bsdi.com> <20000619172041.G37084@prism.flugsvamp.com> <20000619153325.D17420@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 19, 2000 at 03:33:25PM -0700, Alfred Perlstein wrote: > * Jonathan Lemon <jlemon@flugsvamp.com> [000619 15:17] wrote: > > On Mon, Jun 19, 2000 at 02:56:47PM -0700, Mike Smith wrote: > > > > > > Kblob is not a new output method. It's a bolt-on to the 'write' > > > interface, as opposed to, say, zero-copy I/O. > > > > Yes, it is a "bolt-on" thing, not a well designed item. > > Yes it is, it serves the purpose for which it was created. For which it is a very specific problem, and I'm trying to expand it a little bit so it can be used for other things as well. > > > > And for a lot of cases > > > > you don't need stuff to actually go to user space. In many situations, > > > > you will receive data, perform operations on a very small part of it, > > > > and then send the data elsewhere, whether to disk or network. > > > > > > However, for a user-space application to do this, you want it to come out > > > to user-space, right? > > > > No. You cut out what I wrote - you may only need a very small part > > of the data to actually go to user space. > > So then use my soon to be committed accept filters to accomplish this. How is this applicable? The accept filters just delay telling the user when data is available, not redirect the data. > > > > Again, this is not addressed in the kblob API. Don't throw sendfile() > > > > up as an example, because I want the data to be kept in the kernel > > > > after being read from disk. > > > > > > It is. You remember that thing called the buffer cache? > > > > Not applicable here. If it was, why the heck aren't you using sendfile > > in the first place and relying on the kernel to keep the file cached? > > Hmm? If that was the way things worked, why isn't sendfile() good enough? > > Because of all the damn overhead of vm operations that you won't > be satisfied about until I bog down kblob with them. It's not > going to happen. I'm not advocating that. I'm simply trying to get a better API to start out with. Heck, you were standing right next to me at the SMP meeting when I was discussing this with Jeffrey Hsu at length, I thought you were also listening. What I was proposing does not use any VM operations. > > Exactly. You're looking at kblob as a "static send-only buffer which > > comes from user space". I'm looking at kblob as an "in-kernel object > > cache". The two views are _NOT_ that far apart, and with a little API > > help, the current code can be made much more flexible. Why are you > > opposed to that? > > I'm not opposed to it at all, feel free to work on the code as much > as you want as long as you don't kill the fastpath it offers. Sure, as long as you don't mind me ripping out your API later, and replacing it with something which accomplishes the same thing but is more flexible. > > > If you have a Grand Plan for something else, that's great - I'd recommend > > > you keep working on it. In the meantime, there are a lot of people that > > > can do a lot of useful things with kblob as-is, and knocking it down just > > > because it's not _your_ idea of the Perfect In-Kernel Network Container > > > Object is kinda silly. > > > > Well, with a little more work, we can get something that is more > > applicable to a wider audience, rather than focusing on your single > > specific performance problem. Putting on blinders to the wider > > problem simply because your current code doesn't address it strikes > > me as kind of foolish. > > The only problem I see is that there's just no pleasing some people. > :) > > I'm not writing this code for your application Johnathan, I'm > writing it for myself and for the other people that need this > functionality. Fine. I'm not complaining about your functionality, I'm complaining about your API. In one of my last messages, I presented a list of things I wanted to accomplish with in-kernel buffers. Now, I don't explect you to implement the code for it, but I also don't expect you to stick with such a narrow API that makes those aims impossible to accomplish in the future. -- Jonathan 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?20000619175805.J37084>