From: Evgeniy Polyakov <[EMAIL PROTECTED]> Date: Fri, 21 Jul 2006 13:39:09 +0400
> On Fri, Jul 21, 2006 at 02:19:55AM -0700, David Miller ([EMAIL PROTECTED]) > wrote: > > From: Evgeniy Polyakov <[EMAIL PROTECTED]> > > Date: Fri, 21 Jul 2006 13:06:11 +0400 > > > > > Receiving side, nor matter if it is socket or netchannel, will drop > > > packets (socket due to queue overfull, netchannels will not drop, but > > > will not ack (it's maximum queue len is 1mb)). > > > > > > So both approaches behave _exactly_ the same. > > > Did I miss something? > > > > Socket will not drop the packets on receive because sender will not > > violate the window which receiver advertises, therefore there is no > > reason to drop the packets. > > How come? > 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. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
