Date: Thu, 11 Aug 2011 11:30:29 +1000 From: Lawrence Stewart <lstewart@freebsd.org> To: Slawa Olhovchenkov <slw@zxy.spb.ru> Cc: Steven Hartland <killing@multiplay.co.uk>, Andre Oppermann <andre@freebsd.org>, freebsd-net@freebsd.org Subject: Re: tcp failing to recover from a packet loss under 8.2-RELEASE? Message-ID: <4E4330B5.5030100@freebsd.org> In-Reply-To: <20110805065743.GC94016@zxy.spb.ru> References: <E18D678F05BB4F3B93ADEB304CCA8504@multiplay.co.uk> <1F95A4C2D54E4F369830143CBDB5FF86@multiplay.co.uk> <4E37C0F2.4080004@freebsd.org> <2B063B6D95AA4C27B004C50D96393F91@multiplay.co.uk> <C706DEE346684B8DB06CFC090F556E72@multiplay.co.uk> <4E3AA66A.6060605@freebsd.org> <20110805065743.GC94016@zxy.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On 08/05/11 16:57, Slawa Olhovchenkov wrote: > On Fri, Aug 05, 2011 at 12:02:18AM +1000, Lawrence Stewart wrote: [snip] >> >> The real fix which is somewhere down on my todo list is to make all >> these memory constraints elastic and respond to VM pressure, thus >> negating the need for a hard limit at all. This would solve many if not >> most of the TCP tuning problems we currently have with one foul swoop >> and would greatly reduce the need for tuning in many situations that >> currently are in the "needs manual tuning" basket. > > Autotunig w/o limits is bad idea. This is way to DoS. Depends how it is implemented. With appropriate backpressure mechanisms put in place, it could be perfectly safe. I envisage reassembly segments being at the bottom of the heap in terms of importance, so if a machine were to come under memory pressure, they would be the first thing to be reclaimed. TCP would continue to operate if they got pulled out from under the connection as the protocol doesn't consider segments held in reassembly to have been delivered, so would recover via retransmission. > May be solved this trouble by preallocation "hidden" element in tqe > for segment received in valid order and ready for send to application? > T.e. when creating reassembled queue for tcp connection we allocation > queue element (with room for data payload), used only when data ready > for application. Allocation in queue for not breaking ABI (don't > change struct tcpcb). I'm not sure I quite follow what you're suggesting here, but I think Andre's proposed patch achieves the same goal and is arguably cleaner? Cheers, Lawrence
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E4330B5.5030100>