Re: [PATCH] splice support #2
From: Jens Axboe
Date: Thu Mar 30 2006 - 07:13:30 EST
On Thu, Mar 30 2006, Ingo Molnar wrote:
>
> * Jens Axboe <axboe@xxxxxxx> wrote:
>
> > On Thu, Mar 30 2006, Ingo Molnar wrote:
> > >
> > > * Jens Axboe <axboe@xxxxxxx> wrote:
> > >
> > > > Hi,
> > > >
> > > > This patch should resolve all issues mentioned so far. I'd still like
> > > > to implement the page moving, but that should just be a separate
> > > > patch.
> > >
> > > neat stuff. One question: why do we require fdin or fdout to be a pipe?
> > > Is there any fundamental problem with implementing what Larry's original
> > > paper described too: straight pagecache -> socket transfers? Without a
> > > pipe intermediary forced inbetween. It only adds unnecessary overhead.
> >
> > No, not a fundamental problem. I think I even hid that in some comment
> > in there, at least if it's decipharable by someone else than myself...
> > Basically I think it would be nice in the future to tidy this a little
> > bit and separate the actual container from the pipe itself - and have
> > the pipe just fill/use the same container.
>
> why is there a container needed at all? If i splice pagecache->socket,
> we can use sendpage to send it off immediately. There is no need for any
> container - both the pagecache and sendpage use struct page, and when we
> iterate to create a container we might as well ->sendpage() those pages
> off immediately instead.
>
> I agree with the purpose of making sys_splice() generic and in
> particular usable in scripts/shells where pipes are commonly used, but
> we should also fulfill the original promise (outlined 15 years ago or
> so) and not limit this to pipes. That way i could improve TUX to make
> use of it for example ;)
There's absolutely no reason why we can't add fd -> fd splicing as well,
so no worries. Right now we just require a pipe transport. It's
extendable :-)
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/