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

[Ingo Molnar]

On Thu, 18 Jan 2001, Andrea Arcangeli wrote:

> Agreed. However since TCP_CORK logic is more generic than MSG_MORE
> [...]

why? TCP_CORK is equivalent to MSG_MORE, it's just a different
representation of the same issue. TCP_CORK needs an extra syscall (in the
case of a push event - which might be rare), the MSG_MORE solution needs
an extra flag (which is merged with other flags in the send() case).

> > i believe it should rather be a new setsockopt TCP_CORK value (or a new
> > setsockopt constant), not an ioctl. Eg. a value of 2 to TCP_CORK could
> > mean 'force packet boundary now if possible, and dont touch TCP_CORK
> > state'.
>

> Doing PUSH from setsockopt(TCP_CORK) looked obviously wrong because it
> isn't setting any socket state, [...]

well, neither is clearing/setting TCP_CORK ...

> and also because the SIOCPUSH has nothing specific with TCP_CORK, as
> said it can be useful also to flush the last fragment of data pending
> in the send queue without having to wait all the unacknowledged data
> to be acknowledged from the receiver when TCP_NODELAY isn't set.

huh? in what way does the following:

{
        int val = 1;
        setsockopt(req->sock, IPPROTO_TCP, TCP_CORK,
			(char *)&val,sizeof(val));
        val = 0;
        setsockopt(req->sock, IPPROTO_TCP, TCP_CORK,
			(char *)&val,sizeof(val));
}

differ from what you posted. It does the same in my opinion. Maybe we are
not talking about the same thing?

> Changing the semantics of setsockopt(TCP_CORK, 2) would also break
> backwards compatibility with all 2.[24].x kernels out there.

[this is nitpicking. I'm quite sure all the code uses '1' as the value,
not 2.]

	Ingo