linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Mielke <mark@mark.mielke.cc>
To: "Pål Halvorsen" <paalh@ifi.uio.no>
Cc: bert hubert <ahu@ds9a.nl>, linux-kernel@vger.kernel.org
Subject: Re: sendfile
Date: Wed, 30 Apr 2003 18:18:34 -0400	[thread overview]
Message-ID: <20030430221834.GA23109@mark.mielke.cc> (raw)
In-Reply-To: <Pine.SOL.4.51.0304302317590.13406@thrir.ifi.uio.no>

On Wed, Apr 30, 2003 at 11:57:59PM +0200, P?l Halvorsen wrote:
> On Wed, 30 Apr 2003, bert hubert wrote:
> > On Wed, Apr 30, 2003 at 09:12:17PM +0200, P?l Halvorsen wrote:
> > > It could be useful for applications like streaming video where other
> > > protocols on top provide additional functionality or in a multicast
> > > session where TCP migth not be appropriate.
> > sendfile on UDP would try to send gigabits per second over ppp0...
> YES, I guess sendfile will send "count" bytes as fast as possible using
> UDP. However, can't sendfile be called several times, allowing the
> sender to keep track of the offsett and byte count, e.g., sending the
> data needed for a second video each second? Or does sendfile
> close the file/socket after each call (really making it useful for only
> whole file transfers at a time like retrieving a www-document)?

At some point, I would wonder 'why'? I've always considered the real
benefit of sendfile() that the system never has to fully swap your
process in, in order to do work on your behalf as would be necessary
with read() and write(). The zero copy architecture doesn't seem
significant to me if you are going to wait between sendfile()
requests.

> > > But should not the 2.4.X kernels have support for chained sk_buffs (like
> > > the BSD mbufs) meaning that support for scatter-gatter I/O from the NIC
> > > should be unneccessary to support zero-copy (i.e., NO in-memory data
> > > copy operations)?
> > No clue what you mean over here. Zero copy means different things to
> > different people. Sendfile eliminates the 'read(to buffer);write(buffer to
> > network);' copy.
> First, zero-copy for me is to have no copy operations from one main memory
> location to another (not counting the transfer from disk to memory and
> from memory to NIC). Thus, I would like to read data into one memory
> location and transfer the same data form the same location to the NIC.

To some degree, couldn't sendto() fit this description? (Assuming the kernel
implemented 'zero-copy' on sendto()) The benefit of sendfile() is that
data isn't coming from a memory location. It is coming from disk, meaning
that your process doesn't have to become active in order for work to be
done. In the case of UDP packets, you almost always want a layer on top
that either times the UDP packet output, or sends output in response to
input, mostly defeating the purpose of sendfile()...

mark

-- 
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/


  reply	other threads:[~2003-04-30 21:59 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-30 14:28 sendfile Pål Halvorsen
2003-04-30 16:51 ` sendfile bert hubert
2003-04-30 19:12   ` sendfile Pål Halvorsen
2003-04-30 19:28     ` sendfile bert hubert
2003-04-30 21:57       ` sendfile Pål Halvorsen
2003-04-30 22:18         ` Mark Mielke [this message]
2003-04-30 22:34           ` sendfile Pål Halvorsen
2003-05-01  4:28             ` sendfile Mark Mielke
2003-05-01 15:25               ` sendfile Joseph Malicki
2003-05-01 21:17               ` sendfile Pål Halvorsen
2003-05-01 22:31                 ` sendfile Chris Friesen
2003-05-01 23:32                   ` sendfile Ketil Froyn
2003-05-02  9:02                     ` sendfile Bernd Eckenfels
2003-05-02  2:41                   ` sendfile Mark Mielke
2003-05-02  4:19                     ` sendfile Chris Friesen
2003-05-02 21:06                       ` sendfile Mark Mielke
2003-05-03  0:42                         ` sendfile Miquel van Smoorenburg
2003-05-03 15:04                           ` sendfile Mark Mielke
2003-05-03 12:52                         ` sendfile Pål Halvorsen
2003-05-03 21:01                         ` sendfile Pål Halvorsen
2003-05-04  0:53                           ` sendfile Miquel van Smoorenburg
  -- strict thread matches above, loose matches on Subject: below --
2001-05-24  8:44 sendfile Pål Halvorsen

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=20030430221834.GA23109@mark.mielke.cc \
    --to=mark@mark.mielke.cc \
    --cc=ahu@ds9a.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paalh@ifi.uio.no \
    /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).