lkml.org 
[lkml]   [1999]   [Jan]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: TCP Splice alleviates proxy bottleneck
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.026 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site