FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=release%2F13.2.0 2020-06-03T18:42:28Z 2020-06-03T18:42:28Z John Baldwin jhb@FreeBSD.org 2020-06-03T18:42:28Z urn:sha1:093a8f8daf309b6cefc6a9f3ebd217938fcceb6a 2020-06-02T00:32:36Z Kyle Evans kevans@FreeBSD.org 2020-06-02T00:32:36Z urn:sha1:f45b1312960772485acf4b4c8f35a0cfb4f3dfbf IPSEC_SUPPORT can currently only cope with either IPSEC || IPSEC_SUPPORT, not both. Refrain from building if IPSEC is set, as the resulting module won't be able to load anyways if it's built into the kernel. KERN_OPTS is safe here; for tied modules, it will reflect the kernel configuration. For untied modules, it will defer to whatever is set in ^/sys/conf/config.mk, which doesn't set IPSEC for modules. The latter situation has some risk to it for uncommon scenarios, but such is the life of untied kernel modules. Reported by: jenkins (a lot), O. Hartmann (once) Generally discussed with: imp, jhb 2020-05-30T00:47:03Z John Baldwin jhb@FreeBSD.org 2020-05-30T00:47:03Z urn:sha1:1319a761796820b1a67820f2537aaeeec9f77bdf Honoring the kernel-supplied opt_ipsec.h in r361632 causes builds of ipsec modules to fail if the kernel doesn't include IPSEC_SUPPORT. However, the module can never be loaded into such a kernel, so only build the modules if the kernel includes IPSEC_SUPPORT. Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D25059 2020-05-29T19:21:35Z John Baldwin jhb@FreeBSD.org 2020-05-29T19:21:35Z urn:sha1:4bcbd26ff8ba994b042e655dd2c865f3722c0899 To make this simpler, set the default contents of opt_ipsec.h for standalone modules in sys/conf/config.mk. Reviewed by: imp MFC after: 2 weeks Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D25046 2019-09-24T18:18:11Z Randall Stewart rrs@FreeBSD.org 2019-09-24T18:18:11Z urn:sha1:35c7bb340788f0ce9347b7066619d8afb31e2123 is a completely separate TCP stack (tcp_bbr.ko) that will be built only if you add the make options WITH_EXTRA_TCP_STACKS=1 and also include the option TCPHPTS. You can also include the RATELIMIT option if you have a NIC interface that supports hardware pacing, BBR understands how to use such a feature. Note that this commit also adds in a general purpose time-filter which allows you to have a min-filter or max-filter. A filter allows you to have a low (or high) value for some period of time and degrade slowly to another value has time passes. You can find out the details of BBR by looking at the original paper at: https://queue.acm.org/detail.cfm?id=3022184 or consult many other web resources you can find on the web referenced by "BBR congestion control". It should be noted that BBRv1 (which this is) does tend to unfairness in cases of small buffered paths, and it will usually get less bandwidth in the case of large BDP paths(when competing with new-reno or cubic flows). BBR is still an active research area and we do plan on implementing V2 of BBR to see if it is an improvement over V1. Sponsored by: Netflix Inc. Differential Revision: https://reviews.freebsd.org/D21582 2019-07-10T20:40:39Z Randall Stewart rrs@FreeBSD.org 2019-07-10T20:40:39Z urn:sha1:3b0b41e6132bb1ba529d20a9ecf4817f0478d6d5 well as sets in some of the groundwork for committing BBR. The hpts system is updated as well as some other needed utilities for the entrance of BBR. This is actually part 1 of 3 more needed commits which will finally complete with BBRv1 being added as a new tcp stack. Sponsored by: Netflix Inc. Differential Revision: https://reviews.freebsd.org/D20834 2018-07-24T14:55:47Z Randall Stewart rrs@FreeBSD.org 2018-07-24T14:55:47Z urn:sha1:399973c33d862e8860ecda55664179de0dd2e7bc was only put in has an example. Sponsored by: Netflix inc. Differential Revision: https://reviews.freebsd.org/D16420 2018-06-07T20:57:12Z Randall Stewart rrs@FreeBSD.org 2018-06-07T20:57:12Z urn:sha1:401e870791c6cbd833e0b6503d9fb9f941b9b178 Reported by: Peter Lei 2018-06-07T18:18:13Z Randall Stewart rrs@FreeBSD.org 2018-06-07T18:18:13Z urn:sha1:89e560f441bb214495715039288c99442b3b5aea Rack includes the following features: - A different SACK processing scheme (the old sack structures are not used). - RACK (Recent acknowledgment) where counting dup-acks is no longer done instead time is used to knwo when to retransmit. (see the I-D) - TLP (Tail Loss Probe) where we will probe for tail-losses to attempt to try not to take a retransmit time-out. (see the I-D) - Burst mitigation using TCPHTPS - PRR (partial rate reduction) see the RFC. Once built into your kernel, you can select this stack by either socket option with the name of the stack is "rack" or by setting the global sysctl so the default is rack. Note that any connection that does not support SACK will be kicked back to the "default" base FreeBSD stack (currently known as "default"). To build this into your kernel you will need to enable in your kernel: makeoptions WITH_EXTRA_TCP_STACKS=1 options TCPHPTS Sponsored by: Netflix Inc. Differential Revision: https://reviews.freebsd.org/D15525 2017-03-27T18:20:32Z Michael Tuexen tuexen@FreeBSD.org 2017-03-27T18:20:32Z urn:sha1:4222f9685c59013425ddbc1ee8c474536a56494e to build the tcp modules. Sponsored by: Netflix, Inc.