Date: Thu, 11 Oct 2018 22:11:36 -0700 From: Ryan Moeller <ryan@ixsystems.com> To: net@freebsd.org Subject: 11-stable TCP reassembly queue Message-ID: <C6EB3FF8-33E4-43D3-B388-CDEA15570AC6@ixsystems.com>
next in thread | raw e-mail | index | archive | help
There are some reports of network dropouts associated with the max TCP reassembly queue length: https://forums.freenas.org/index.php?threads/11-1u6-update-transfer-aborts-on-smb-share-mac-client.69553/ <https://forums.freenas.org/index.php?threads/11-1u6-update-transfer-aborts-on-smb-share-mac-client.69553/>; https://forums.freenas.org/index.php?threads/network-issues-after-upgrading-to-11-1-u6.69506/ <https://forums.freenas.org/index.php?threads/network-issues-after-upgrading-to-11-1-u6.69506/>; I am aware that a sysctl can be adjusted to increase the maximum queue length if needed. However, I am curious if the default might be a bit low. Can anyone offer some advice on how to determine a rational limit to set? To offer an additional data point: on my own desktop system (11.2-RELEASE-p2) there are currently 3191 discarded segments. I'm not sure if this is an unusually high number, and I honestly wouldn't have realized it was happening if I hadn’t been looking at my own stats out of curiosity. The most significant network activity for this machine is fetching code from GitHub or downloading package updates. I occasionally scp files to/from a macOS laptop over wifi. It seems a bit odd that my moderate traffic would be exceeding the default threshold at all. Is this to be expected? I saw the TCP reassembly improvements in https://reviews.freebsd.org/D16471 <https://reviews.freebsd.org/D16471>; and wonder if this is perhaps related. Finally, I see that a rewrite of the TCP reassembly code addressing the inefficiency underlying the original security concern has been committed to 12-CURRENT, and this is great for FreeBSD 12+, but it seems like it probably won’t be merged into the stable branches. Can anyone confirm that is the case? Thanks, Ryan Moeller
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C6EB3FF8-33E4-43D3-B388-CDEA15570AC6>