Messages in this thread | | | Date | Thu, 18 Jan 2001 21:44:57 +0100 (CET) | From | Ingo Molnar <> | Subject | Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]] |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |