]> CyberLeo.Net >> Repos - FreeBSD/stable/8.git/commit
MFC r213913:
authorlstewart <lstewart@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Sat, 6 Nov 2010 10:31:52 +0000 (10:31 +0000)
committerlstewart <lstewart@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Sat, 6 Nov 2010 10:31:52 +0000 (10:31 +0000)
commit954dabbdc76f978a3fd972520625a0652bd3d89d
tree639d7fee9d80f572fdce3d2d4e7117eeda46d9e8
parent70337fe5e6e3d9621b553821c2d7cfe3e205c9e3
MFC r213913:

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

git-svn-id: svn://svn.freebsd.org/base/stable/8@214866 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
sys/netinet/tcp_reass.c