netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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).