Date: Sat, 16 Oct 2010 07:12:39 +0000 (UTC) From: Lawrence Stewart <lstewart@FreeBSD.org> To: cvs-src-old@freebsd.org Subject: cvs commit: src/sys/netinet tcp_reass.c Message-ID: <201010160712.o9G7CvuG013066@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
lstewart 2010-10-16 07:12:39 UTC
FreeBSD src repository
Modified files:
sys/netinet tcp_reass.c
Log:
SVN rev 213913 on 2010-10-16 07:12:39Z by lstewart
Retire the system-wide, per-reassembly queue segment limit. The mechanism is far
too coarse grained to be useful and the default value significantly degrades TCP
performance on moderate to high bandwidth-delay product paths with non-zero loss
(e.g. 5+Mbps connections across the public Internet often suffer).
Replace the outgoing mechanism with an individual per-queue limit based on the
number of MSS segments that fit into the socket's receive buffer. This should
strike a good balance between performance and the potential for resource
exhaustion when FreeBSD is acting as a TCP receiver. With socket buffer
autotuning (which is enabled by default), the reassembly queue tracks the
socket buffer and benefits too.
As the XXX comment suggests, my testing uncovered some unexpected behaviour
which requires further investigation. By using so->so_rcv.sb_hiwat
instead of sbspace(&so->so_rcv), we allow more segments to be held across both
the socket receive buffer and reassembly queue than we probably should. The
tradeoff is better performance in at least one common scenario, versus a devious
sender's ability to consume more resources on a FreeBSD receiver.
Sponsored by: FreeBSD Foundation
Reviewed by: andre, gnn, rpaulo
MFC after: 2 weeks
Revision Changes Path
1.369 +15 -11 src/sys/netinet/tcp_reass.c
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201010160712.o9G7CvuG013066>