public inbox for linux-kernel@vger.kernel.org
 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: Thu, 1 May 2003 00:28:31 -0400	[thread overview]
Message-ID: <20030501042831.GA26735@mark.mielke.cc> (raw)
In-Reply-To: <Pine.SOL.4.51.0305010024180.334@niu.ifi.uio.no>

On Thu, May 01, 2003 at 12:34:32AM +0200, Pål Halvorsen wrote:
> On Wed, 30 Apr 2003, Mark Mielke wrote:
> > 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()...
> Maybe, but then I'll have two system calls...

As I mentioned before, the real benefit to sendfile(), as I understand it, is
that sendfile() makes it unnecessary for the OS to fully activate the calling
process in order to do work for the calling process. Unless you can point out
some other benefit provided by sendfile(), I fail to see how you will do:

    while (1) {
        send_frame_over_udp();
        sleep();
    }

Without two system calls. Whether send_frame_over_udp() uses sendfile() as
you seem to want it to, or whether it just calls sendto(), doesn't make a
difference. Because one of your requirements is that you need to provide a
smooth feed, the primary benefit of sendfile(), that of not having to activate
your process, becomes invalid.

I haven't done timings, or looked deeply at this part of linux-2.5.x,
however, I fail to see why the following code should not meet your
requirements:

    void *p = mmap(0, length_of_file, PROT_READ, MAP_SHARED, fd, 0);
    off_t offset = 0;

    while (offset < length_of_file)
      {
        int packet_size = max(512, length_of_file - offset);
        send(socket, &p[offset], packet_size, 0);
        offset += packet_size;
        usleep(packets_size * 1000000 / packets_per_second);
      }

In theory, send() should be able to provide the zero copy benefits you
are requesting. In practice, it might be a little harder, but in this
case, from my perspective, send() and sendfile() should both provide
equivalent performance. Why would sendfile() perform better than send()?

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-05-01  4:09 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         ` sendfile Mark Mielke
2003-04-30 22:34           ` sendfile Pål Halvorsen
2003-05-01  4:28             ` Mark Mielke [this message]
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=20030501042831.GA26735@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