Новость вызывает у меня бурю эмоций, и я еле-еле сдерживаюсь, чтобы не начать тролить.Начинаем читать отсюда: https://en.wikipedia.org/wiki/TCP_offload_engine
и главное доходим до Support in Linux.
Пока другие операционные системы (Windows и FreeBSD) активно занимались разработкой собственных решений по оптимизации сетевого Linux ни черта не умел, при чем из принципа. Кстати, в конечном итоге Microsoft сдалась, закрыла свои потуги и адоптировала решения из BSD.
Затем мир перешел на оптические адаптеры по 10, 25 и выше гигабит, и оказалось, что все механизмы Offloading и QoS на самом деле очень нужны, особенно когда дело касается сетевых адаптеров с высокой пропускной способностью. Их нужно правильно готовить с Active Queue Management-ом c LRO/LSO, профилировать Interrupt Moderation, настраивать Receive Side Scaling и с учетом многпроцессорных систем и современных Scalable-процессоров (для режима Sub NUMA Clustering). Всё это существует годами, но в Linux про это мало что знают. А потом вообще пришла RDMA... но тут не в ней дело.
И вот спустя годы Linux оказался без нормального API в ядре для работы со всем этим.
Спасибо Open Fabrics (https://www.openfabrics.org/) за OFED-драйверы
Спасибо DPDK (https://www.dpdk.org/), что и в Linux есть API, но только в юзерспейсе (в этом смысл DPDK)
Результат который мы наблюдаем сейчас:
1. Драйвер Bonding в ядре - это страшный мусор, который нужно удалить. Он не поддерживает вообще ничего
2. LRO, LSO, RSS и Interrupt Moderation есть, но по большей части всё это находится в драйверах
3. Автоматических настроек, профилирования нет. Народ даже ethtool до конца не понимает
4. QoS и AQM на принимающей стороне сетевого стека отсутствует, вместо него есть возможность что-то наваять на **tables.
5. Linux Virtual Switch - мусор из 90-х, который не отвечает современным потребностям
А потом спрашивается, а чего это все коммутаторы проприетарные, даже те, в которых Linux используется... Ну ок, есть Cumulus Linux (желаю удачи его скачать), но он живой пример, как можно сделать проприетарь на базе GPL.
Стыд в том, что настольная версия Windows всё это поддерживает правильно и позволяет себя перенастроить... Шел 2023-й год и в Linux задумались, что у них в сетевом стеке что-то не так. Вся эта беспробудная тупость усугубляется тем, что слишком много людей в Linux верующие фанатики. На этот раз они верят в то, что сетевки Intel - нормальные. Нет! Это адаптеры, в которых сломаны все эти механизмы и в которых каждый год выходит обновление драйвера, выпиливающее что-нибудь, потому что нашли баги. В общем в 2023-ем году вне Mellanox и Chelsio жизни нет. И если в том же Linux максимально пользоваться из драйверами и минимально всем что есть в системе, то оно будет работать.
Дальше эти фантазии про QoS. Я ведь зашел на унылый лендинг LibreQoS (ускорятеля видеоигр через QoS). Я даже видео посмотрел. Было сложно, было стыдно, но я посмотрел! Причем они рассказывают про игры, будто это домашнее решение.
Давайте на минуточку забудем про LibreQoS и ISP-задачи и поговорим, как должен выглядеть современный QoS...
(тем кто в таке гуглите слова сами)
Вот вы включили AQM на стороне сетевого адаптера и роутера. Вы настроили Weghted Random Early Detection (WRED) и Explicit Congestion Notification, который радостно прописался в ваши заголовки IP. Допустим вы настроили DCTCP (Datacenter TCP) как Congestion Control вместо CUBIC и начали уважать ECN для задач управления потоком TCP. Но этого мало, вы должны использовать иерархический QoS для реального разграничения трафика, то есть ваш коммутатор поддерживает Enhanced Transmission Selection (ETS).
У вас нормальный такой коммутатор/роутер, но сетевой адаптер тоже должен всё это уметь (Intel свой забудьте). Например, вы купили NVIDIA/Mellanox и радостно настроили OFED, очереди и QoS, благо для Linux это можно сделать средствами прошивки и драйвера.
И вот он наконец-то у вас появился ваш QoS. Красивый иерархический с дележками на типы трафика и резервацией буфера, с поддержкой Assured Forwwarding (предоставления гарантированной пропускной способности канала). Дальше что?!
DSCP вам удалят при попадании пакетов из вашей сети в сеть провайдера, если только вы не купили L1 через DWDM или L2VPN. А что пройзойдет с QoS, когда провайдер перемаркирует DSCP? Правильно ваш QoS и ваш Congestion Control разуплотняется на субатомные частицы.
А если у вас Datacenter и Storage-сети поверх Ethernet, ваш QoS обязан держать Flow Control на приоритетах 802.1p с использованием Priority Based Flow-controil (PFC) и затем трансформировать их в DSCP в направлении вашей L3-фабрики. Сочетание AQM(WRED)+ETS+ECN+PFC=DCQCN Datacenter Quantized Congestion Notification.
Применение DCQCN позволяет:
- полностью убрать slowstart-образные механизмы и полагаться на PFC, устанавливая соединения со скоростью линка
- не терять пакеты вообще (нет ретрансмитов), потому что у вас ECN сообщает заранее о грядущей перегрузке
- а если источник потока не снизил скорость (Transmission Rate), то за дело возьмётся PFC
Естественно и ваши коммутаторы и ваши сетевые адаптеры поддерживают решения типа PFC Watchdog средствами прошивки, потому что PFC-это peer-to-peer QoS и он может штормить при неверной настройке.
И вот они ваши сетевки наконец-то получили пакеты в буферы. Ура!
Что там за проблема у вас? Снижение задержек на TCP? Обычно люди для таких вещей UDP используют (те же P2P-сети обозначенных в видосе видеоигр), а большинство оффлоадингов типа Large Recieve Offload, он же Receive Segment Coalescing, он же Generic Receive Offload не затрагивает протокол UDP по вполне очевидной причине. В UDP в общем случае нет понятия сессий, и сетевой адаптер не поймет как склеивать UDP пакеты перед отправкой в CPU.
Так что же тогда делает LibreQoS?! И почему пишет про чятики и видеоигры?
То есть какую задачу он решает? Что такое случилось? Предлагает собственную реализацию поллинг из буфера NIC? Собсвенную реализацию RSS? И с каких пор шейпинг помагает задержкам?! Шейпинг их создаёт!!! В этом его суть, он уберает Packet Burst внутрь буфера вместо того чтобы дропнуть или ставить на паузу (PFC) или уведомлять заранее (WRED) огрядущей перегрузке очередей, средствами ECN? Чем они вообще там занимаются?
А давайте посмотрим сюда:
https://libreqos.readthedocs.io/en/latest/docs/Quickstart/ne...
Ох ёж твою медь! Это решение для мамкиного ISP!
Оно не поддерживает MPLS (я не удивлён) и скорее всего VXLAN тоже, причем эти странные личности пишут про OSPF... то есть не eBGP+ECMP, а вот именно OSPF, ну да ладно, это мелочи. Главное что оно сервис в смысле Service Chaining включения, как граничный файрвол, DPI и прочий NAT-перенат. Оно заворачивает на себя декапсулированный трафик. А может задержки снизятся если этой штуки вообще там нет, а вместо этого у вас просто есть QoS на сетевом оборудовании?
Лучше сделать не как бомжи, а распространить Diffserv-домен на всю свою L3-фабрику и сделать правильный мапинг к PCP-приоритетам на L2-границе. Зачем этот костыль, который под капотом решает только одну единственную проблему, проблему убогости ядра Linux и его сетевого стека. И вот после героического решения проблем убогости они на Linux (создание логики очередей поверз eBPF) они создают волшебный QoS, который средствами шейпинга (sic!) снижает задержки. А про уменьшение буферизации за счет установки дополнительного сервера в цепочку на выходе трафика - это прямо анекдот. Ох, что люди только не придумают лишь бы Diffserv не настраивать.
Я к тому что такие решения существуют но они не бесплатные. Тот же SQN QoS, когда теннанты инкапсулируются в VXLAN. Они есть даже как продукты, которые ставятся на Linux, главное только настоящий трафик туда не заворачивать. Оркестрировать и мониторить можно, только не заворачивать трафик, потому что Linux и QoS... ой всё.
Может проще Juniper купить? Или что вам там больше нравится, только нормальное?
P.S. Я такой едкий сегодня, потому что это псевдопродукт, с красивым лендингом, весь такой ускоряющий видеоигры и зумы. А на самом деле - это сервисчейн, который ставит мультифилд-классификаторы и шейпит один трафик в угоду другому, причем так, что создаёт бутылочное горлышко. Я бы понял, если бы это преподносилось как очередной раковый шейпер, который VK сделает быстрее, а Youtube медленнее и привяжет это к тарифной сетке:
https://libreqos.readthedocs.io/en/latest/docs/TechnicalDocs...
Ой, так это же оно и есть!
