Из ядра Linux удалена поддержка UDP Fragmentation Offload

ЯННП. Что это?

Сетевой интерфейс раньше мог «аппаратно» распиливать большие UDP-пакеты на фрагменты, влезающие в PMTU. Сейчас эта операция всегда делается программно.

А как поступят в LTS-релизах систем? Непонятно... Роллинг-релизы понятно, а эти? Даже если удалят из дистрибутивов Linux с 1 годом поддержки, то это будет понятно: на этих дистрах же «обкатываются» будущие LTS-ы.

В бубунте например, ядра обновляются. И в 16.04.5 уже этого точно не будет.

бэкпортируют, думаю

А как поступят в LTS-релизах систем?

Удалят. Это всего лишь (опасная, как оказалось) оптимизация.

удалена поддержка UDP Fragmentation Offload

Зачем фиксить баги? У нас нет времени долбаться с ними.
Лучше ещё раз запилить $YET_ANOTHER_IPC. А потом пропатчить CFS.
А потом опять IPC.

С одной стороны да, печально. А с другой стороны, кому нафиг нужно делать оффлоад фрагментации UDP на сетевую карту?

Опять новый ничок? :-)

Подобные вещи обычно бэкпортируют вплоть до 3.x.

Добавляют новые возможности - ядро раздувается, плохо. Выкидывают ненужное, что случайно нашли по багу, - тоже плохо.

Удалить нельзя пофиксить.

в качестве решения проблемы предложил удалить поддержку

А если в программе rm найдут возможность повреждения памяти — её удалят?

Да. Предлагаю сделать форк без опции --force уже сейчас

Ты гляди, что мой полный тёзка-растоман вытворяет, из-за него теперь в ядре нет мега-полезной фичи, которая повышала мне FPS'ы в Quake! Теперь колёсики в glxgears будут крутиться медленнее и винда под VB тяжело грузится начнёт. А всё потому что увлечение Rust'ом вот до такого доводит! :(

Сетевой интерфейс раньше мог «аппаратно» распиливать большие UDP-пакеты на фрагменты, влезающие в PMTU. Сейчас эта операция всегда делается программно.

Какого *** контролем соединений занимается ядро ОС, а не драйвер сетевых соединений?

И вообще, какого *** драйвера то встраивают, то удаляют из ядра ОС? Отделите уже наконец-то мух от коклеты, товарищи из Kernel Team!

Какого *** контролем соединений занимается ядро ОС, а не драйвер сетевых соединений?

Что еще за драйвер сетевых соединений? Сетевая карта обычно должна ловить трафик и передавать его ОС, а уже ОС будет из этого строить соединения.

Какого *** контролем соединений занимается ядро ОС, а не драйвер сетевых соединений?

Школьник чтоль? Ну ничего, на первом курсе ИТ проходят сетевые технологии и операционные системы. Все впереди. :)

UDP Fragmentation Offload - UFO. Вот где они были, эти зелёные человечки.

Если ошибка в дизайне, и функционал в конечном итоге не теряется, то можно удалить.

rm на всяких самсунгобуках вроде как умело удалять efivars, вам этого недостаточно? :)

Спс, поржал с утреца :D.

Линукс - что ни баг, то получение прав рута.

в качестве решения проблемы предложил удалить поддержку

Впрочем, ничего нового.

Вот прям команда

ethtool -k eth0 | grep udp-fragmentation-offload

в качестве решения проблемы предложил удалить поддержку

Популярное, смотрю, решение. Пусть ядро удалят вообще, там по любому багов полно, чё, их же отлавливать и исправлять еще надо, а это сложно.

Линукс - что ни баг, то получение прав рута.

Ну а как еще? В домашней венде ж из-под рута все и так работают

Э, чувак... Обновись, win98 немножко устарела

Популярное, смотрю, решение. Пусть ядро удалят вообще, там по любому багов полно, чё, их же отлавливать и исправлять еще надо, а это сложно.

Если эта фича никому не нужна, но добавляет сложный путь обработки, на который нужно тратить время — да, её проще удалить.

Э, чувак... Обновись, win98 немножко устарела

счастливый человек, который не знает фразу «симерка моксемальная»?

круто

А если в программе rm найдут возможность повреждения памяти — её удалят?

Сначала ее встроят в ядро. А потом — да, удалят.

Возможно его где-то случайно укусил гномер.

Популярное, смотрю, решение. Пусть ядро удалят вообще, там по любому багов полно, чё, их же отлавливать и исправлять еще надо, а это сложно.

Если эта фича никому не нужна, но добавляет сложный путь обработки, на который нужно тратить время — да, её проще удалить.

Фича предлогаемая Торвальдсом на kernel.org тоже нужна от силы 2% пользователей ЭВМ.

Чем биткойны майнить, лучше бы фаззеры массово гоняли.

(Из побочных эффектов - ядро и прочий софт похудеют вдвое)

2% пользователей ЭВМ.

каждому линуксоиду?

У редхата ещё 2.6.32 на регулярной поддержке, а для некрокастомеров с 5кой на расширенной поддердке, думаю, и 2.6.18 пропатчат.

Фича предлогаемая Торвальдсом на kernel.org тоже нужна от силы 2% пользователей ЭВМ.

Если ты зашлешь в рассылку «привет чуваки, кому нужен Linux?» ты увидишь много откликов «мне». Если ты зашлешь туда же «кому нужен UDP offload» ты увидишь молчание в ответ. Так понятнее?

А каким образом вообще Linux ядро выполняет фрагментацию UDP datagram? То есть, на основе какого RFC был реализован данный механизм? И какие приложения используют данный механизм?

RFC 768: User Datagram Protocol, не содержит для этого необходимых сведений, RFC 8085: UDP Usage Guidelines содержит следующие строки:

RFC 8085: UDP Usage Guidelines

«3.2. Message Size Guidelines

IP fragmentation lowers the efficiency and reliability of Internet communication. The loss of a single fragment results in the loss of an entire fragmented packet, because even if all other fragments are received correctly, the original packet cannot be reassembled and delivered. This fundamental issue with fragmentation exists for both IPv4 and IPv6.

In addition, some network address translators (NATs) and firewalls drop IP fragments. The network address translation performed by a NAT only operates on complete IP packets, and some firewall policies also require inspection of complete IP packets. Even with these being the case, some NATs and firewalls simply do not implement the necessary reassembly functionality; instead, they choose to drop all fragments. Finally, [RFC4963] documents other issues specific to IPv4 fragmentation.

Due to these issues, an application SHOULD NOT send UDP datagrams that result in IP packets that exceed the Maximum Transmission Unit (MTU) along the path to the destination. Consequently, an application SHOULD either use the path MTU information provided by the IP layer or implement Path MTU Discovery (PMTUD) itself [RFC1191][RFC1981] [RFC4821] to determine whether the path to a destination will support its desired message size without fragmentation.

...

Applications that fragment an application-layer message into multiple UDP datagrams SHOULD perform this fragmentation so that each datagram can be received independently, and be independently retransmitted in the case where an application implements its own reliability mechanisms.»

Собственно говоря это и логично, ведь есть TCP, который и призван осуществлять сегментацию на транспортном уровне или SCTP, если TCP не подходит из каких-то соображений.

А в случае, когда ядро выполняет фрагментацию UDP datagram, то ситуация выглядит даже хуже чем IP фрагментация. Поскольку UDP заголовок не имеет вообще не каких полей, для определения номера фрагмента, а каждый datagram согласно RFC является законченным сообщением с точки зрения транспортного уровня.

Я предполагаю, что возможно мне не удалось правильно сформировать запрос, чтобы найти больше информации, как получилось и почему самое главное, что была реализована фрагментация UDP datagram.

RFC 8085 - Это BCP а не нормативный документ, т.е. рассуждения на тему что «вот хорошо бы было если бы так». К тому-же этот документ весьма свеж (чуть больше полугода)

rm на всяких самсунгобуках вроде как умело удалять efivars

Срочно удалить!

Ну а как еще? В домашней венде ж из-под рута все и так работают

Обновляться с Win 9x пробовал?

Спасибо, я теперь хотя бы знаю, как это смотреть :)

Верно, это указано в заголовке документа, что это Best Current Practice и он заменил более старую версию, под другим номером от 2008 года. Но, как это отвечает на заданные мною вначале моего сообщения вопросы?

Я к тому, что RFC 768 имеет статус INTERNET STANDARD и гласит следующие:

«This protocol provides a procedure for application programs to send messages to other programs with a minimum of protocol mechanism. The protocol is transaction oriented, and delivery and duplicate protection are not guaranteed. Applications requiring ordered reliable delivery of streams of data should use the Transmission Control Protocol (TCP)[2].»

Это не означает, что за реализацию UDP datagram fragmentation, должны отлучать от сети, но тем не менее, какова была мотивация реализации UDP datagram fragmentation в ядре Linux? И каким образом соблюдается факт транзакционной ориентированности протокола в таком случае?

Вот, что мне удалось найти в документации ядра:

«UDP Fragmentation Offload =========================

UDP fragmentation offload allows a device to fragment an oversized UDP datagram into multiple IPv4 fragments. Many of the requirements for UDP fragmentation offload are the same as TSO. However the IPv4 ID for fragments should not increment as a single IPv4 datagram is fragmented.»

Иными словами речь идёт о IP fragmentation, а значит мои вопросы можно считать исчерпанными.

Да да, всем диванным экспертам обязательно нужна была поддержка Large segment offload.

А каким образом вообще Linux ядро выполняет фрагментацию UDP datagram? То есть, на основе какого RFC был реализован данный механизм?

На основе RFC 791. Т.е. это просто фрагментация IP-пакетов без флага «DF», примененная к UDP.

Да, я нашёл всё таки документацию, но в любом случае спасибо за ответ. :)

диванным экспертам

которые спецы по диванным котикам?

приятно что местная идея о нинужна побеждает!