lkml.org 
[lkml]   [2003]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: sendfile
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/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:35    [W:0.067 / U:0.472 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site