Вы "немножечко переоцениваете" то, что называется сетевым стеком. Всё что вы перечислили Linux-специфичное барахло.

Начнем с главного: исторически сложилось что протокол TCP используется везде, даже там, где это не нужно, потому что, опять исторически, в Ethernet-сетях не работает congestion control, а у протокола TCP есть многолетняя история развития костылей вокруг собственного CC внутри транспортного протокола. Но не TCP единым,.. особенно после пришествия QUIC.

Так вот, в сетевых устройствах принято выносить специфические рутины на отдельные чипы (ASIC-и), которые должны заниматься реализацией той или иной функции/протокола. Linux - это уникальная операционная система, которая объявила бойкот этой практике и боролась с объективной реальностью +/- до 2007-го года, лишь бы не заниматься протоколосепцифичными разгрузками (offload) и не разрабатывать собственный стандарт сетевого стека, готового для частичного переноса нагрузки на ASIC сетевого адаптера. https://en.wikipedia.org/wiki/TCP_offload_engine
При этом речь не только о разгрузке TCP, но и о других синтетических ускорениях вроде:
- RSS (Receive Side Scaling). Он нужен, чтобы утилизировать ваши десятки гигабит на оптических адаптерах. Одно ядро не способно обработать более 5 гигабит на приём, нужно распараллеливать по ядрам
- Large Send Offload (он же Generic Send Offload, он же TCP/UDP Segmentation Offload). Он нужен для того чтобы не дробить пакеты по 1500 байт на шине PCI-Express. Нормальный сетевой адаптер пересегментирует сессионные протоколы на базе UDP (вроде QUIC) и протокол TCP изменив MSS так чтобы отправка из ядра (из CPU) была в 64KB, а сетевка сама перефрагментировала на заказанное L2MTU 1514 или 9014. Это чудовищно экономит ресурсы цетрнального процессора.
- Interrupt Moderation. Вам нужен контроль прерываний, чтобы сетевой адаптер не сразу прерывал выполнения всех процессо юзерспейса ради приёма одного пакета, а ждал накомпления нескольких.
- Large Receive Offload (он же Generic Receive Offload, он же Receive Segment Coalescing). Нужен, когда в сочетании с контролем прерываний и его буферизацией вы не просто их посылаете на процессор, но также меняете TCP MSS. Это аналог LSO только для приёма, а не для отдачи.
- Hardware QoS Offload позволяет производить маркировку, BA-классификацию и расчёт цветов полисеров прямо на сетевом адаптере. В сочетании с поддержкой иерархического QoS и Priority-based Flow Control это даёт вам возможность генерировать почти Lossless-сеть. Когда к этому добавляется Explicit Congestion Notification вы можете использовать DCTCP в вашем датацентре и DCQCN, если пользуетесь RDMA.
- Собственно RDMA. Один портирован из Infiniband (RoCEv2) второй на базе полной собственной реализации TCP-стека на прошивке адаптера (iWarp) для создания обмена данными между буферами в RAM по сети без участия центрального процессора. Нужно для стораджей NVMe и Persistand Memory (Optane и аналогичные)
- ODX (Offload data Transfer). Разгрузка FCP и iSCSI на ASIC. Нужно для SAS-хранилищ.
- Encapsulated Task Offload. VLAN, VXLAN, NVGRE, но не GENEVE) могут быть декапсулированы и инкапсулированы заново сетевым адаптером без участия CPU.
Ну и там еще есть всякие мелочи вроде хардварной реализации расчета сумм, точного времени и в редких случаях даже некоторых шифров TLS для разгрузки ядерной реализации TLS, если в системе есть крипто-ASIC.

Windows имела свой стек разгрузок, но уже в Server 2012 отказалась от них и начала переносить всё из BSD. А вот в Linux с этим исторически боролись, а вендоры сетевок совместно с FreeBSD всё это придумывали и реализовывали. Пока в один прекрасный момент до них не дошло, что даже полностью софтварная реализация буферов LRO/RSC растит производительность в 1,5 раза.

Подавляющее большинство того что я написал доступно в Linux, но не средствами ядра, а средствами DPDK, который заботливо написал Intel сразу после того как прикрыл большую часть своих линеек сетевых адаптеров, повыпиливал все старые Windows-специфичные разгрузки и не скатился до такой степени, что его не вытеснили с рынка Mellanox и Chelsio. DPDK заполняет вакуум в Linux по конфигурации вендорских драйверов. Вендоры драйверов при этом в рамках проекта OpenFabric пишут совместимые дрова с идеями из FreeBSD и Windows, а в Linux этот функционал просто есть, потому что его вендоры принесли. Чтобы его задействовать вы пишете своё ПО в юзерспейсе используя DPDK. Обратно перенести такой софт, кстати, тоже можно. Можно написать софт завязанный на DPDK и потом использовать в других ОС. FreeBSD и Windows тоже могут в DPDK.

> nftables

nftables или iptables не имеет значение. Это реализация файрволла в модуле netfilter. Файрволл есть в каждой ОС. Самый продвинутый функционально продвинутый файрволл (и самый медленный) - это Windows Firewall, потому что в совокупности с другими сервисами он способен построить демилитаризованную зону вокруг каждого клиентского устройства. Требовать Kerberos-предаутентификацию перед установкой простых TCP-соединений на протоколах, которые это не умели и пошифровать всё в Ipsec. Однако он медленный и очень корпоративный, для аппаратных решений не подходит. Реализации хардварных файрволлов долгое были на FreeBSD, но теперь можно и Linux иметь в виртуалочке и называть это NGFW.

> всякими io_uring

А при чем здесь это вообще? Всем известно что асинхронные операции ввода-вывода в ядре Linux были проблемными. Причем проблемными настолько, что проще было по максимуму унести всё это в юзерспейс. В Windows NT, например, за снижение приоритета потока обрабатывающего последующий ввод-вывод после прерывания отвечает Deferred Procedure Call (DPC). Аналогично можно в принципе в юзерспейсный поток положить (Threaded DPC). В BSD при этом существует куча готовых структур данных и инструкций по обмену данными между ядром и сетевым адаптером / HBA. Их радостно портировали в Windows Server 2022/Windows 11. Наряду с кучкой CC и других плюшек. Я к тому, что io_uring это не преимущество, а решение проблемы убожества прошлой реализации AIO.

Вообще надо бы вспомнить, что реализация Linux Virtual Switch из 90-х (подачка от IBM) и драйвер бондинга в Linux настолько плохие, что даже Windows Server 2012 умел лучше, хотя в Windows c L2 было всё плохо. Сейчас в венде опять всё переписали и там другие драйверы отвечают за виртуальные коммутаторы и бондинг, но сам факт!

Единственный кусок Linux, который нормально работает - это Open vSwitch и конкретно драйвер бриджинга. Причем все остальные вещи настолько ужасны, что проще использовать только его, если хочется воспользоваться разгрузками на сетевых адаптерах. Ну то есть всё что есть в ядре даже с учётом, что вы написали свои софтинки вокруг DPDK и задействовали функционал OFED-драйверов работает только в том случае, если вы не пользуетесь бондингом и виртуальным свитчом, а делаете всё на бриджах.

В очень крупных развертываниях размеров с Google и Amazon это так и делается:
- у вас в датацентре L3-фабрики, реализующие андерлей
- у вас используется BGP для организации интерьерной маршрутизации
- у вас используется EVPN для мультихоуминга узлов виртуализации и контейнерных кластеров
- у вас используется ECMP для балансировки потоков/соединений по L3-фабрике.
В этой ситуации вы берете все свои сетевые порты и укладываете в мост. Там вы поднимаете оверлей. Расчёт хэш-сумм для потоков что ECMP, что для RSS у вас идёт одними и теми же средствами. QoS и Data Center Bridging тоже работают, потому что старые убогие дрова из ядра не включены.

Если же вы подняли LACP и агрегируете L2 - вы огребете тонну проблем на многопроцессорных материнках (так везде), потеряете тонну оффлоада и не сможете задействовать ASIC-и адаптера (специфика Linux). Попрощаетесь с RDMA и так далее. Собственно оно всё тюнится только под такой юзкейс, потому что корпоративные размеры (100-3000 узлов виртуализации) с разными форматами сетей в разных локациях Linux "не могёт". Облачные - другое дело. Опять же, я не говорю, что это не возможно создать облачную сеть в корпоративных масштабах... просто администраторы Linux привыкли крутить свой Proxmox или в лучшем случае oVirt и даже слыхом не слыхивали про то, что есть нормальные сетевки и свитчи, и что можно снизить нагрузку на хост виртуализации, воспользовавшись этим функционалом. Или они вращают кубернетисы в виртуалках на VMware, а это тоже не располагает к понимаю бареметала и синтетических ускорений.

Вообще, всю эту стену текста я писал чтобы обсудить вот эту ерунду:
> MPTCP

Это бредовенький способ разносить соединение по разным IP/маршрутам который переписали так, что версия v0 и v1 не совместимы ни в какую сторону? Навязчивое желание использовать Multipath TCP - это явный признак непонимания сетей. Очень часто встречается у Linux-админов, потому что они не просто сеть не знают. Они обычно свои тулзы в Linux для этой сети не понимают.

Вся эта идиотская идея притащить всё в TCP уже признана ущербной (даже RPC-протоколы начали переводить на QUIC). Она не находит массового применения. В нормальных операционных системах, таких как FreeBSD, ESXi и Windows для организации Multipath используется 2 метода:
1. Использовать сеть и разносить соединения по хэшам в привязке к RSS, его аналогичных решениях для виртуализации вроде VMMQ в Hyper-V с одной стороны и ECMP на стороне сетей. В условиях наличия EVPN и ESI-LAG вы можете даже L3-гейтвей повесить на Anycast-адреса близлежащих ToR-свитчей, чтобы была полная балансировка нагрузки. Так, кстати, можно делать и в Linux, но при условии, что вы не будете пользоваться родным старым сетевым стеком ядра. В других ОС, вам хватит LACP для аггрегации и при наличии MLAG на стороне вышестоящих свитчей, вы не потеряете в балансировке.
2. Реализовать Multipath на L7. То есть если у вас есть приложение или протокол пользовательского типа вы можете предусмотреть возможность использовать несколько сессий TCP и сами дробить по ним трафик по своему усмотрению. Например, SMB Multichannel так делает.

Тут настоящая проблема в производительности MPTCP!

С одной стороны, чтобы использовать разгрузки в OFED-драйверах вам нужно учесть MPTCP, когда вы производите LRO и LSO. С другой стороны (RSS) в зависимости от приложения вам нужно собрать итоговый поток... на каком ядре? В общем случае для RSS ядро строит Indirection Table и посылает его в драйвер адаптера. Несколько аппаратных очередей (для QoS и потоковой передачи) можно разнести по нескольким физическим ядрам. Indirection Table передаёт в прошивку матрицу соответствия и динамически её обновляет без перезагрузки сервера/адаптера. И вот у вас есть процесс приложения, который открыл куда-то там TCP-соединение. Вы настроили MPTCP, чтобы оно расползлось по разным потокам, пусть для примера их 2.
- Потоки могут прийти на одно и тоже ядро или на разные.
- Ваше приложение висит в одном потоке исполнении на одном ядре или на нескольких
- Учтите специфику SMT/HyperThreading. Получение данных по сети работает на физических ядрах, а потоки вашего приложения могут висеть на SMT-ядрах.
- Учтите NUMA. А на каких сокетах у вас сетевки и ваша соплекуха. Ну допустим на одном и том же единственном процессоре.
И вот я стесняюсь спросить вы как вообще в этой ситуации будете собирать этот поток и эффективно обрабатывать из него данные в приложении?!
Отсюда и возникает необходимость писать не generic-решение, а решение задачи специфичное для приложения.

А вообще, пока Windows не внедрит MPTCP и не выведет его в прод для всех клиентских тачек, он будет оставаться вычурным стандартам "не для всех". А этого не случится пока campus-сеть не поднимется выше гигабита.

P.S. Хохмы ради приведите мне живой пример TCP-сессии, которую нужно разделить на пополам? Причем с архитектурной точки зрения приведите такой пример, чтобы нужно было именно дожидаться реализации MPTCP в ядрах всех операционных систем, во всех ASIC-ах и всех сетевых адаптерах, а не переписать костыльное приложение, снабдив его другим транспортным протоколом вроде QUIC или старенького SCTP (для телефонных/медиа задачек) или установив 2 сессии самостоятельно на стороне приложения.