Messages in this thread | | | From | (Larry McVoy) | Subject | Re: TCP Splice alleviates proxy bottleneck | Date | Mon, 18 Jan 1999 23:16:22 -0800 |
| |
To answer Alan's question about originality: the only parts about the short splice paper which I think are original are
a) the idea of loaned vs gift pages. b) the observation that Unix traffics in user level VM when what it should traffic in is physical page vectors. c) the idea of splice() being a library call which calls the system calls pull() and push() to do the work. d) the idea of taking this approach and applying it to file systems, networking, user VM, everything.
The push/pull stuff is pretty interesting because it can handle all the corner cases where there is what I am fond of calling "a performance impedance mismatch". it also handles stuff like fanning a bunch of sources to one sink; something that the traditional splice() models can't do at all.
But the last one is main point. I'm a real fan of having models that don't fall apart when you add another client, and the physical page model seems to work regardless of who is the client. It's quite simple when you think about it for even a few seconds - under all those layers of abstractions - if you are talking about I/O - there has to be physical pages because that's what the devices want. So all I/O is
get some data from some external source put it in some physical pages wrap some abstraction (file, socket, whatever) around it hand it to a user
or the reverse.
However, the idea of taking the splice model I described and applying it to everything may prove to be its downfall - that's a lot of work to chew off. I suspect it would keep even Linus busy for 6 months or more to do a good job of it, so mere mortals could count on a year or so.
Anyway, as to the other papers, I'm unfamiliar with the IBM work, I scanned the paper and thought it looked cool but I have no idea what was their inspiration.
The IO lite stuff I like, and I once called Vivek and told him so. In fact, I campaigned to get it published once.
On both of those papers, both the stength and the weakness is that they address just one area of the I/O model. That's cool because it means they scooped out a problem which could actually be solved, but it is less than perfect because they aren't thinking about 100% of the I/O picture.
If I ever get to the point that I don't need money and the push/pull/splice stuff still isn't in Linux, I'll take a crack at it. But I expect that could be as far as 4 years away so if there is anyone out there who wants to take a crack at it and get all the glory, I'd be happy to offer an advice I could on the side.
--lm
Chuck Lever <cel@monkey.org>: : On Mon, 18 Jan 1999 lk@winux.com wrote: : > Date: Mon, 18 Jan 1999 23:36:12 -0500 (EST) : > From: lk@winux.com : > To: Alan Cox <alan@lxorguk.ukuu.org.uk> : > Cc: linux-kernel@vger.rutgers.edu : > Subject: Re: TCP Splice alleviates proxy bottleneck : > : > Alan Cox writes: : > > From: alan@lxorguk.ukuu.org.uk (Alan Cox) : > > To: lk@winux.com : > > Cc: alan@lxorguk.ukuu.org.uk, linux-kernel@vger.rutgers.edu : > > Subject: Re: TCP Splice alleviates proxy bottleneck : > > Date: Mon, 18 Jan 1999 14:53:14 +0000 (GMT) : > > : > >> Their work on TCP Splice gives the efficiency of IP masquerading, yea, : > >> even that of simple IP forwarding, to processes with the capabilities : > >> of application level proxies. : > > : > > Their ? Having looked at the reference I'd like Larry McVoy's opinion on : > > its originality 8) : > : > I'm not sure what you mean by this. Are you referring to Larry McVoy's : > paper "Splice - a push pull I/O model for Unix" dated 6/24/98 [1]? : > : > If so, the model he presents is a bit different than theirs. A cursory : > reading of his paper indicates to me that his model is intended to be : > more general, i.e. not intended purely for TCP/IP, and as such it (rightly) : > glosses over most of the TCP/IP-specific issues that Pravin and Maltz : > address in their paper dated 3/17/98 [2]. They also have the advantage of : > having implemented their ideas. : : Druschel and Pai *have* implemented IO-Lite, which seems similar in spirit : to McVoy's ideas. see: : : http://www.cs.rice.edu/~vivek/IO-Lite/TR97-294.ps : : i think this would be a great starting place for what you have in mind. a : combination of the general zero-copy I/O semantics and the TCP-specific : improvements could be very slick. : : > References: : > : > [1] http://www.bitmover.com/lm/papers/splice.ps : > [2] http://www.cs.umd.edu/users/pravin/TR-21139.ps.gz : : - Chuck Lever : -- : corporate: <chuckl@netscape.com> : personal: <chucklever@netscape.net> or <cel@monkey.org> : : : - : To unsubscribe from this list: send the line "unsubscribe linux-kernel" in : the body of a message to majordomo@vger.rutgers.edu : Please read the FAQ at http://www.tux.org/lkml/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |