From: Jens Axboe <jens.axboe@oracle.com>
To: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Cc: David Miller <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: [PATCH][RFC] network splice receive
Date: Tue, 12 Jun 2007 13:33:54 +0200 [thread overview]
Message-ID: <20070612113352.GA18832@kernel.dk> (raw)
In-Reply-To: <20070612112950.GA16477@2ka.mipt.ru>
On Tue, Jun 12 2007, Evgeniy Polyakov wrote:
> On Sat, Jun 09, 2007 at 08:36:09AM +0200, Jens Axboe (jens.axboe@oracle.com) wrote:
> > On Fri, Jun 08 2007, Evgeniy Polyakov wrote:
> > > On Fri, Jun 08, 2007 at 06:57:25PM +0400, Evgeniy Polyakov (johnpol@2ka.mipt.ru) wrote:
> > > > I will try some things for the nearest 30-60 minutes, and then will move to
> > > > canoe trip until thuesday, so will not be able to work on this idea.
> > >
> > > Ok, replacing in fs/splice.c every page_cache_release() with
> > > static void splice_page_release(struct page *p)
> > > {
> > > if (!PageSlab(p))
> > > page_cache_release(p);
> > > }
> >
> > Ehm, I don't see why that should be necessary. Except in
> > splice_to_pipe(), I have considered that we need to pass in a release
> > function if mapping fails at some point. But it's probably best to do
> > that in the caller, since they have the knowledge of how to release the
> > pages.
> >
> > The rest of the PageSlab() tests are bogus.
>
> I had a crashdump, where page was released via splice_to_pipe() indeed,
> I did not investigate if it is possible to release provided page in
> other places. I think if in future there will other slab usage cases
> except networking receiving, that might be useful, but as is it is not
> needed.
Read the just posted code, it has moved way beyond this :-)
> > > and putting cloned skb into private field instead of
> > > original on in spd_fill_page() ends up without kernel hung.
> >
> > Why? Seems pointless to allocate a clone just to hold on to the skb, a
> > reference should be equally good. I would not be opposed to doing it
> > this way, I just don't see what a clone buys us as compared to just
> > holding that reference to the skb.
>
> Receiving code does not expect shared skbs - too many fields are changed
> with assumptions that it is a private copy.
Actually the main problem is that tcp_read_sock() unconditionally frees
the skb, so it wouldn't help if we grabbed a reference to it. I've yet
to receive an explanation of why it does so, seem awkward and violates
the whole principle of reference counted objects. Davem??
So for now, skb_splice_bits() clones the incoming skb to avoid that. I'd
hope we can get rid of that by fixing tcp_read_sock(), though.
--
Jens Axboe
next prev parent reply other threads:[~2007-06-12 12:08 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-05 8:05 [PATCH][RFC] network splice receive Jens Axboe
2007-06-05 11:45 ` Jens Axboe
2007-06-05 12:20 ` Jens Axboe
2007-06-05 12:34 ` jamal
2007-06-06 7:14 ` Jens Axboe
2007-06-05 13:34 ` Evgeniy Polyakov
2007-06-05 14:31 ` Evgeniy Polyakov
2007-06-05 14:49 ` Evgeniy Polyakov
2007-06-06 7:17 ` Jens Axboe
2007-06-07 8:09 ` Evgeniy Polyakov
2007-06-07 10:51 ` Jens Axboe
2007-06-07 14:58 ` Evgeniy Polyakov
2007-06-08 7:48 ` Jens Axboe
2007-06-08 8:06 ` David Miller
2007-06-08 8:38 ` Jens Axboe
2007-06-08 8:56 ` Evgeniy Polyakov
2007-06-08 9:04 ` Jens Axboe
2007-06-08 13:58 ` Evgeniy Polyakov
2007-06-08 14:14 ` Jens Axboe
2007-06-08 14:57 ` Evgeniy Polyakov
2007-06-08 15:19 ` Jens Axboe
2007-06-08 15:30 ` Evgeniy Polyakov
2007-06-09 6:36 ` Jens Axboe
2007-06-12 11:29 ` Evgeniy Polyakov
2007-06-12 11:33 ` Jens Axboe [this message]
2007-06-12 12:35 ` Evgeniy Polyakov
2007-06-12 12:40 ` Jens Axboe
2007-06-12 13:11 ` Evgeniy Polyakov
2007-06-12 13:11 ` Jens Axboe
2007-06-11 8:00 ` Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070612113352.GA18832@kernel.dk \
--to=jens.axboe@oracle.com \
--cc=davem@davemloft.net \
--cc=johnpol@2ka.mipt.ru \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).