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

[Andrea Arcangeli]

On Thu, Jan 18, 2001 at 08:43:47PM +0100, Ingo Molnar wrote:
> 
> On Thu, 18 Jan 2001, Andrea Arcangeli wrote:
> 
> > I'm all for TCP_CORK but it has the disavantage of two syscalls for
> > doing the flush of the outgoing queue to the network. And one of those
> > two syscalls is spurious. [...]
> 
> i believe a network-conscious application should use MSG_MORE - that has
> no system-call overhead.

Agreed. However since TCP_CORK logic is more generic than MSG_MORE and so it
still makes sense for some usage I think it worth to optimize the TCP_CORK
logic too and this new functionality _may_ be useful not just for TCP_CORK.

> > +	case SIOCPUSH:
> > +		lock_sock(sk);
> > +		__tcp_push_pending_frames(sk, tp, tcp_current_mss(sk), 1);
> > +		release_sock(sk);
> > +		break;
> 
> 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, 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.

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

Andrea