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