Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

[Ingo Molnar]

On Wed, 17 Jan 2001, dean gaudet wrote:

> with the linux TCP_CORK API you only get one trailing small packet.
> in case you haven't heard of TCP_CORK -- when the cork is set, the
> kernel is free to send any maximum size packets it can form, but has
> to hold on to the stragglers until userland gives it more data or pops
> the cork.

TCP_CORK has been basically replaced by MSG_MORE these days. The problem
with the cork approach is that it's a persistent socket flag - and it
easily triggers programming errors when the application writer tracks the
state of the cork incorrectly. Also, removing the cork is one extra
system-call. So what you can do with MSG_MORE is to specify at
sendmsg()/writev() time, whether at the end of the buffer there is a cork
or not.

this is what TUX uses. When a eg. static HTTP request arrives it sends
reply headers shortly after having checked file permissions and stuff (but
the file is not yet sent), with MSG_MORE set. Then it sends the file, and
sendfile() keeps MSG_MORE set right until the end of the request, when it
clears it for the last fragment so the last partial packet gets flushed to
the network. In fact there is one more optimization here, if the request
is not keepalive then TUX still kees MSG_MORE set, and closes the socket -
which will implicitly flush the output queue anyway and send any partial
packet, but will also have the FIN packet merged with the last outgoing
packet.

(if there is saturation then further merging might happen as well - if a
sendmsg() comes before a partial, but already xmit-queued packet is sent,
then the TCP layer merges this sendmsg() output with the outgoing packet.)

	Ingo