public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Mielke <mark@mark.mielke.cc>
To: Chris Friesen <cfriesen@nortelnetworks.com>
Cc: "Pål Halvorsen" <paalh@ifi.uio.no>, "bert hubert" <ahu@ds9a.nl>,
	linux-kernel@vger.kernel.org
Subject: Re: sendfile
Date: Thu, 1 May 2003 22:41:47 -0400	[thread overview]
Message-ID: <20030502024147.GA523@mark.mielke.cc> (raw)
In-Reply-To: <3EB1A029.7080708@nortelnetworks.com>

On Thu, May 01, 2003 at 06:31:05PM -0400, Chris Friesen wrote:
> Pål Halvorsen wrote:
> >As far as i understand mmap/send, you'll have a copy operation in the
> >kernel here. mmap shares the kernel and user buffer, but when sending the
> >packet data is copied to the socket buffer!!??
> Yes, there is a copy there.

As far as I understand, sendfile() still requires the data to get from the
disk to a page in memory, similar to how send() referencing an mmap()'d page
may cause a page fault, reading the data from disk to a page in memory. One
copy each. I don't know of a kernel interface that lets data be copied from
disk to ethernet card without involving a temporary copy to be in paged
memory at some point in time... perhaps the iSCSI stuff can do this? I dunno.

Somebody else pointed out that mmap() may not yet be implemented completely
optimally. I will have to look at the code before I continue to make my
'in theory' comments, however the following 'NOTE' in the manpage for sendfile
makes me suspect that sendfile() is very similar to mmap()/write():

       -- CUT --
       Presently the descriptor from which data is read cannot correspond to a
       socket, it must correspond to a file which supports mmap()-like  opera-
       tions.
       -- CUT --

> >OK, but I understand that my streaming scenario is not the target
> >application for sendfile.
> What stops you from using sendfile (with TCP) to each destination 
> separately, with the client only reading from the pipe as needed 
> (presumably with a number of frames worth of buffer on the client side)?

TCP isn't very well suited for video feeds. First, it is streamed, which
makes it a little annoying to ensure that only whole frames get through.
Second, its acknowledgement scheme prefers reliability over low latency.

I'm hoping for good things from SCTP. From what I've read, it looks as
if it should provide a compromise between TCP and UDP that is quite
optimal.

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/


  parent reply	other threads:[~2003-05-02  2:23 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             ` 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                   ` Mark Mielke [this message]
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=20030502024147.GA523@mark.mielke.cc \
    --to=mark@mark.mielke.cc \
    --cc=ahu@ds9a.nl \
    --cc=cfriesen@nortelnetworks.com \
    --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