Re: Netchannles: first stage has been completed. Further ideas.

[Evgeniy Polyakov <johnpol@2ka.mipt.ru>]

On Fri, Jul 21, 2006 at 02:46:23AM -0700, David Miller (davem@davemloft.net) wrote:
> > sk_stream_rmem_schedule(), sk_rmem_alloc and friends...
> 
> sk_stream_rmem_schedule() allocates bytes from the global memory pool
> quota for TCP sockets.  It is not something will trigger when, for
> example, application blocks on a disk write.
> 
> In fact it will rarely trigger once size of window is known, since
> sk_forward_alloc will grow to fill that size, then statically stay
> at the value being able to service all allocation requests in the
> future.
> 
> Only when there is severe global TCP memory pressure will it be
> decreased.
> 
> And again this isn't something which happens when a user simply
> blocks on some non-TCP operation.

Of course it is not, but something that breaks header prediction will
fall into memory check and so on.
Blocking on write will not trigger memory limits overcommit from the
first packet, as long as it will not trigger timeout retransmit if no
acks are sent. If there will be a lot of them, then troubles start.
We saw already, that speed decreased to the write speed in both 
implementations without connection collapsing.

-- 
	Evgeniy Polyakov