После обновления FreeBSD на одном из узлов с 13.X на 14.X столкнулся с внезапным увеличением времени выполнения резервного копирования на столько, что задания перестали успевать выполниться за день, что блокировало выполнение уже новых заданий.

Данный узел географически вынесен на другую площадку, и для обеспечения его сетевой доступности используются IPSec туннели через публичные каналы, и, что вполне естественно, на этих каналах присутствуют потери пакетов. Поиск в сети выдавал рекомендации по изменению различный параметров TCP, таких как:

net.inet.tcp.abc_l_var=44
net.inet.tcp.minmss=536
net.inet.tcp.mssdflt=1220
net.inet.tcp.sendbuf_max=16777216
net.inet.tcp.recvbuf_max=16777216
net.inet.tcp.sendbuf_inc=16384

Также попались рекомендации по настройке H-TCP и BBR, которые, судя по описанию, должны подходить для разнесённых сетей с большим временем ответа и потярями.

Но, к сожалению, применение всех этих рекомендаций ничего не дало. При этом было обнаружено, что проблемы со скоростью передачи данных наблюдаются только в jail контейнере, который получает доступ в сеть через bridge, построенный на хост системе.

Т.е. при запуска с основной системы iperf3 показывал вполне разумные значения скорости передачи данных для 100Mbit/s канала:

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-30.01  sec   163 MBytes  45.6 Mbits/sec  366             sender
[  5]   0.00-30.00  sec   162 MBytes  45.3 Mbits/sec                  receiver
[  7]   0.00-30.01  sec   167 MBytes  46.8 Mbits/sec  371             sender
[  7]   0.00-30.00  sec   166 MBytes  46.5 Mbits/sec                  receiver
[SUM]   0.00-30.01  sec   330 MBytes  92.4 Mbits/sec  737             sender
[SUM]   0.00-30.00  sec   328 MBytes  91.8 Mbits/sec                  receiver

А из контейнера эта скорость была почти на 2 порядка хуже:

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-30.01  sec  3.50 MBytes   978 Kbits/sec  614             sender
[  5]   0.00-30.00  sec  2.50 MBytes   699 Kbits/sec                  receiver
[  7]   0.00-30.01  sec  3.50 MBytes   978 Kbits/sec  589             sender
[  7]   0.00-30.00  sec  2.50 MBytes   699 Kbits/sec                  receiver
[SUM]   0.00-30.01  sec  7.00 MBytes  1.96 Mbits/sec  1203             sender
[SUM]   0.00-30.00  sec  5.00 MBytes  1.40 Mbits/sec                  receiver

Немного изменив поисковый запрос находим статью на форуме FreeBSD, автор которой также столкнулся с деградацией сетевой производительности после обновления до FreeBSD 14.X, и смог решить данную проблему отключив LRO.

Large Receive Offload (LRO) — это способ увеличения входящей пропускной способности сетевого интерфейса за счёт снижения нагрузки на центральный процессор (C) wikipedia

Т.е. вроде бы разработчики сетевых адаптеров пытаются облегчить жизнь центральному процессору, разработчики FreeBSD пытаются оправдать ожидания предыдущих и включают поддержку этого функционала, а, оказывается, это может быть вредно.

Более того, согласно статье о настройке 10Gb сетевых интерфейсов на официальной wiki FreeBSD, и, в случае, если Ваша система не является конечным узлом и может пересылать TCP данные другим узлам, т.е. является маршрутизатором или мостом (bridge) для других виртуальных машин или контейнеров, рекомендуется отключать не только LRO, но и TCP segmentation offload:

-tso4 -tso6 -lro -vlanhwtso

А что же linux? Почему его пользователи не сталкиваются с этой проблемой? Проверим на нескольких системах параметры сетевого интерфейса:

# ethtool -k enp216s0f0 | grep large-receive-offload
large-receive-offload: off

Потому и не сталкиваются, что по умолчанию LRO выключен. Правда, возможно, у меня просто мало linux на bare metal, и, возможно, в каких-то дистрибутивах LRO включён по умолчанию.

Чей подход в данном случае более правильный вопрос сложный, но то, что на диагностику данной проблемы было убито несколько человекочасов - факт.