*BSD News Article 73402


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!nntp.coast.net!news-res.gsl.net!news.gsl.net!news.mathworks.com!fu-berlin.de!informatik.tu-muenchen.de!lrz-muenchen.de!news
From: Andi Kleen <andi@mlm.extern.lrz-muenchen.de>
Newsgroups: comp.os.linux.networking,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc
Subject: Re: TCP latency
Date: 11 Jul 1996 13:56:30 +0200
Organization: Leibniz-Rechenzentrum, Muenchen (Germany)
Lines: 27
Sender: andi@frob.mlm.extern.lrz-muenchen.de
Distribution: world
Message-ID: <m24tnf9f69.fsf@frob.mlm.extern.lrz-muenchen.de>
References: <4paedl$4bm@engnews2.eng.sun.com>
	<4rfkje$am5@linux.cs.helsinki.fi> <31DC8EBA.41C67EA6@dyson.iquest.net>
	<4rlf6i$c5f@linux.cs.helsinki.fi> <31DEA3A3.41C67EA6@dyson.iquest.net>
	<Du681x.2Gy@kroete2.freinet.de> <31DFEB02.41C67EA6@dyson.iquest.net>
	<4rpdtn$30b@symiserver2.symantec.com> <x7ohlq78wt.fsf@oberon.di.fc.ul.pt>
	<Pine.LNX.3.91.960709020017.19115I-100000@reflections.mindspring.com>
	<4s12la$pm8@enomem.lkg.dec.com>
NNTP-Posting-Host: frob.mlm.extern.lrz-muenchen.de
X-Newsreader: Gnus v5.2.34/Emacs 19.31
Xref: euryale.cc.adfa.oz.au comp.os.linux.networking:44780 comp.unix.bsd.netbsd.misc:3995 comp.unix.bsd.freebsd.misc:23297

matt@3am-software.com (Matt Thomas) writes:

> Radical idea.  Requires no new system calls.  Define some new MSG_ variables
> called MSG_ASYNC, MSG_COMPLETE, and MSG_PARTIAL.  When a sendmsg is done and
> MSG_ASYNC is set in the flags argument, sendmsg(2) will own the data pointed
> to by the supplied msgbuf structure.  sendmsg(2) will return immediately
> with a -1 and errno set to EINPROGRESS.   When the system is done with the
> buffer, it will set MSG_COMPLETE in msg_flags member.  If not all the data
> supplied was consumed, MSG_PARTIAL will also be set and any iovec entry
> will have its iov_len set to the number of bytes not transferred into the
> kernel.  [more needs to be written but you should get the idea.]
> 
> This would allow application such as ftp to directly send data without
> having to copy into the kernel thereby eliminating one data copy.
> 
> Doing the same on receive is much more difficult (but possible).  The idea
> for receive would be to combine the copy to user-space with the checksum
> validation which allow one data reference to eliminated (this assumes that
> checksum failures will be rare).  This would also reduce latency somewhat
> since the window could advance immediately without having to wait for the
> user to do the read/recv.


I think a mmap() interface to sockets would be more elegant (and you could
do exactly the same thing)

-Andi