Re: [PATCH][RFC] network splice receive v3
On Thu, Jul 19 2007, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
> Hello.
>
> In article <[EMAIL PROTECTED]> (at Wed, 11 Jul 2007 11:19:27 +0200), Jens
> Axboe <[EMAIL PROTECTED]> says:
>
> > @@ -835,6 +835,7 @@ const struct proto_ops inet_stream_ops = {
> > .recvmsg = sock_common_recvmsg,
> > .mmap = sock_no_mmap,
> > .sendpage = tcp_sendpage,
> > + .splice_read = tcp_splice_read,
> > #ifdef CONFIG_COMPAT
> > .compat_setsockopt = compat_sock_common_setsockopt,
> > .compat_getsockopt = compat_sock_common_getsockopt,
>
> Please add similar bits in net/ipv6/af_inet6.c
> unless there are any dependency on IPv4.
> (And if there are, it is not good.)
There are no specific ipv4 depedencies, it's just an oversight. So
thanks for the clue, I'll add it!
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RFC] network splice receive v3
Hello.
In article <[EMAIL PROTECTED]> (at Wed, 11 Jul 2007 11:19:27 +0200), Jens Axboe
<[EMAIL PROTECTED]> says:
> @@ -835,6 +835,7 @@ const struct proto_ops inet_stream_ops = {
> .recvmsg = sock_common_recvmsg,
> .mmap = sock_no_mmap,
> .sendpage = tcp_sendpage,
> + .splice_read = tcp_splice_read,
> #ifdef CONFIG_COMPAT
> .compat_setsockopt = compat_sock_common_setsockopt,
> .compat_getsockopt = compat_sock_common_getsockopt,
Please add similar bits in net/ipv6/af_inet6.c
unless there are any dependency on IPv4.
(And if there are, it is not good.)
--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RFC] network splice receive v3
Hi. On Fri, Jul 13, 2007 at 02:21:00PM +0200, Jens Axboe ([EMAIL PROTECTED]) wrote: > > It really looks like the last tree we tested, so if you think additional > > one will not hurt, feel free to ping, so I will completely rebase > > testing tree. > > It would be great if you could retest! There are some minor changes in > there, and some extra testing definitely will not hurt. I've just tested it with 2.6.22 (e1c1e98d2a3f57b22a0d4136c8160e54404aa437 commit) and did not found any problems - after qute big files were transferred there is no observed previously skb leak, no crashes (quite a few debug options are turned on in config) and files are correct on both peers, so it works good. > -- > Jens Axboe -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RFC] network splice receive v3
On Thu, Jul 12 2007, Evgeniy Polyakov wrote: > On Wed, Jul 11, 2007 at 11:19:27AM +0200, Jens Axboe ([EMAIL PROTECTED]) > wrote: > > Hi, > > Hi Jens. > > > Here's an updated implementation of tcp network splice receive support. > > It actually works for me now, no data corruption seen. > > > > For the original announcement and how to test it, see: > > > > http://marc.info/?l=linux-netdev&m=118103093400770&w=2 > > > > The splice core changes needed to support this are now merged in > > 2.6.22-git, so the patchset shrinks to just two patches - one for adding > > a release hook, and one for the networking changes. > > > > The code is also available in the splice-net branch here: > > > > git://git.kernel.dk/data/git/linux-2.6-block.git splice-net > > > > There's a third experimental patch in there that allows vmsplice > > directly to user memory, that still needs some work though. > > > > Comments, testing welcome! > > It looks like you included all bits we found in the previous runs, so > likely it will work good, but so far I have conflicts merging todays git > and your tree in include/linux/splice.h, fs/ext2/file.c, fs/splice.c and > mm/filemap_xip.c. This can be a problem with my tree though. Hmm, the patch should apply directly to the tree as of when I posted this original mail, or any later one. I just tried a rebase, and it rebased fine on top of the current -git as well. So I think the issue is with your tree, sorry! > It really looks like the last tree we tested, so if you think additional > one will not hurt, feel free to ping, so I will completely rebase > testing tree. It would be great if you could retest! There are some minor changes in there, and some extra testing definitely will not hurt. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RFC] network splice receive v3
On Wed, Jul 11, 2007 at 11:19:27AM +0200, Jens Axboe ([EMAIL PROTECTED]) wrote: > Hi, Hi Jens. > Here's an updated implementation of tcp network splice receive support. > It actually works for me now, no data corruption seen. > > For the original announcement and how to test it, see: > > http://marc.info/?l=linux-netdev&m=118103093400770&w=2 > > The splice core changes needed to support this are now merged in > 2.6.22-git, so the patchset shrinks to just two patches - one for adding > a release hook, and one for the networking changes. > > The code is also available in the splice-net branch here: > > git://git.kernel.dk/data/git/linux-2.6-block.git splice-net > > There's a third experimental patch in there that allows vmsplice > directly to user memory, that still needs some work though. > > Comments, testing welcome! It looks like you included all bits we found in the previous runs, so likely it will work good, but so far I have conflicts merging todays git and your tree in include/linux/splice.h, fs/ext2/file.c, fs/splice.c and mm/filemap_xip.c. This can be a problem with my tree though. It really looks like the last tree we tested, so if you think additional one will not hurt, feel free to ping, so I will completely rebase testing tree. > -- > Jens Axboe -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RFC] network splice receive v3
On Wed, Jul 11 2007, Joel Becker wrote: > On Wed, Jul 11, 2007 at 11:19:27AM +0200, Jens Axboe wrote: > > Subject: [PATCH] splice: don't assume regular pages in splice_to_pipe() > > > > Allow caller to pass in a release function, there might be > > other resources that need releasing as well. Needed for > > network receive. > > > > diff --git a/fs/splice.c b/fs/splice.c > > index 3160951..4b4b501 100644 > > --- a/fs/splice.c > > +++ b/fs/splice.c > > @@ -254,11 +254,16 @@ ssize_t splice_to_pipe(struct pipe_inode_info *pipe, > > } > > > > while (page_nr < spd_pages) > > - page_cache_release(spd->pages[page_nr++]); > > + spd->spd_release(spd, page_nr++); > > Rather than requiring the caller set this, shouldn't we just > allow it? Especially given there is only one non-page user? > > while (page_nr < spd_pages) > -page_cache_release(spd->pages[page_nr++]); > +if (spd->spd_release) > +spd->spd_release(spd, page_nr++); > +else > +page_cache_release(spd->pages[page_nr++]); Certainly possible, I think it's cleaner with it always being set though. If it grows other out-of-splice.c users, then your change may be a good idea though. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RFC] network splice receive v3
On Wed, Jul 11, 2007 at 11:19:27AM +0200, Jens Axboe wrote: > Subject: [PATCH] splice: don't assume regular pages in splice_to_pipe() > > Allow caller to pass in a release function, there might be > other resources that need releasing as well. Needed for > network receive. > > diff --git a/fs/splice.c b/fs/splice.c > index 3160951..4b4b501 100644 > --- a/fs/splice.c > +++ b/fs/splice.c > @@ -254,11 +254,16 @@ ssize_t splice_to_pipe(struct pipe_inode_info *pipe, > } > > while (page_nr < spd_pages) > - page_cache_release(spd->pages[page_nr++]); > + spd->spd_release(spd, page_nr++); Rather than requiring the caller set this, shouldn't we just allow it? Especially given there is only one non-page user? while (page_nr < spd_pages) - page_cache_release(spd->pages[page_nr++]); + if (spd->spd_release) + spd->spd_release(spd, page_nr++); + else + page_cache_release(spd->pages[page_nr++]); Joel -- "Any man who is under 30, and is not a liberal, has not heart; and any man who is over 30, and is not a conservative, has no brains." - Sir Winston Churchill Joel Becker Principal Software Developer Oracle E-mail: [EMAIL PROTECTED] Phone: (650) 506-8127 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
