All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <jens.axboe@oracle.com>
To: David Miller <davem@davemloft.net>
Cc: jaschut@sandia.gov, linux-kernel@vger.kernel.org
Subject: Re: splice/vmsplice performance test results
Date: Thu, 16 Nov 2006 22:21:07 +0100	[thread overview]
Message-ID: <20061116212107.GK7164@kernel.dk> (raw)
In-Reply-To: <20061116.155224.08323028.davem@davemloft.net>

On Thu, Nov 16 2006, David Miller wrote:
> From: "Jim Schutt" <jaschut@sandia.gov>
> Date: Thu, 16 Nov 2006 11:08:59 -0700
> 
> > Or is read+write really the fastest way to get data off a
> > socket and into a file?
> 
> There is still no explicit TCP support for splice/vmsplice so things
> get copied around and most of the other advantaves of splice/vmplice
> aren't obtained either.  So perhaps that explains your numbers.

There should not be any copying for tcp send, at least no more than what
sendfile() did/does. Hmm?

> Jens Axboe tries to get things working, and others have looked into it
> too, but adding TCP support is hard and for several reasons folks like
> Alexey Kuznetsov and Evgeniy Polyakov believe that sys_receivefile()
> is an interface much better suited for TCP receive.
> 
> splice/vmsplice has a lot of state connected to a transaction, and
> perhaps that is part of why Evgeniy and Alexey have trouble wrapping
> their brains around an efficient implementation.

I hope to try and see if I can help get some of that done, however I
need all the help I can get on the networking side. Not sure I
understand why it has to be so difficult, if we need to define a wrapper
container instead of passing down a pipe that is completely fine with
me. The networking code basically just needs to hang on to the
pipe_buffer and release it on ack for send, receive is somewhat more
involved (and I don't know enough about networking to voice any
half-intelligent opinion on that!).

I would just consider it a damn shame if we cannot complete the splice
family and need to punt to something else for net receive.

-- 
Jens Axboe


  reply	other threads:[~2006-11-16 21:21 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-16 18:08 splice/vmsplice performance test results Jim Schutt
2006-11-16 20:25 ` Jens Axboe
2006-11-16 21:24   ` Jim Schutt
2006-11-17 17:21   ` Jim Schutt
2006-11-20  7:59     ` Jens Axboe
2006-11-20  8:24       ` Jens Axboe
2006-11-20 15:49         ` Jim Schutt
2006-11-21 13:54           ` Jens Axboe
2006-11-21 19:17             ` Jim Schutt
2006-11-22  8:57               ` Jens Axboe
2006-11-22 22:35                 ` Jim Schutt
2006-11-23 11:24                   ` Jens Axboe
2006-11-27 20:57                     ` Jim Schutt
2006-11-16 20:52 ` David Miller
2006-11-16 21:21   ` Jens Axboe [this message]
2006-11-16 21:27     ` David Miller

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=20061116212107.GK7164@kernel.dk \
    --to=jens.axboe@oracle.com \
    --cc=davem@davemloft.net \
    --cc=jaschut@sandia.gov \
    --cc=linux-kernel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.