Финальный релиз Linux kernel 6.3 запланирован на конец апреля. Одно из примечательных нововведений — увеличение максимального размера TCP-пакета в контексте IPv4.
Зачем нужна эта технология
При работе в 100-гигабитных сетях вычислительные системы оперируют миллионами пакетов за секунду. И у процессора мало времени на выполнение всех задач, связанных с их обработкой. Снизить темп можно, если увеличить размер посылок. Для этих целей применяют методы GRO и TSO. Один агрегирует пакеты в единый блок размером 64 Кбайта для передачи по сетевому стеку, а другой — вновь их сегментирует.
Но в дата-центрах и других высокопроизводительных средах, оперирующих терабайтами и петабайтами данных, число пакетов все равно остается чрезмерно высоким. Решение проблемы — сделать пакеты еще больше, чтобы сильнее сократить их количество. Этой цели и служит технология BIG TCP.
IPv6 был первым
Вообще, BIG TCP — идея не новая. Для протокола IPv6 концепцию описали еще в RFC 2675 в 1999 году, а её поддержку добавили в Linux kernel 5.19. Специальный патч реализовал логику для передачи так называемых jumbo-кадров. При отправке jumbo-пакета система устанавливает 16-битное значение длины посылки на ноль и добавляет заголовок hop-by-hop с её реальной длиной. Поле заголовка включает 32 бита, и это означает, что jumbo-пакет может содержать до 4 Гбайт данных.
Технология значительно увеличила производительность протокола IPv6, особенно в 100-гигабитных сетях. Нововведение с энтузиазмом встретили облачные провайдеры и операторы гиперскейлеров. Установка размера пакета на уровне в 185 Кбайт увеличила пропускную способность на 50% во внутренних сетях дата-центров.
На очереди IPv4
На этой неделе вышел первый релиз-кандидат Linux kernel 6.3-rc1. Разработчики включили в него поддержку BIG TCP для IPv4.
По умолчанию в заголовках IPv4 нельзя указать размер увеличенного пакета. Поэтому в качестве индикатора BIG TCP использовали нулевое значение tot_len. Такой подход приемлем, поскольку кадры BIG TCP — это пакеты GSO/GRO. В них нет паддинга (padding), и skb->len – network_offset представляет собой точный размер пакета IPv4. Для обеспечения соответствующей функциональности разработчики реализовали несколько новых API.
Первые бенчмарки показали рост производительности и пропускной способности с патчем IPv4 BIG TCP.
Другие сетевые изменения
Linux kernel 6.3 включает несколько других дополнений, связанных с сетевыми технологиями. Например, смешение IPv4 и IPv6 в многопутевой модификации Multipath TCP (MPTCP). Также добавят драйвера для нескольких Ethernet-свитчей и пару обновлений, связанных с реализацией WiFi 7.
Больше нововведений можно ожидать в последующих релиз-кандидатах. Но скорее всего, в них не будет новых крупных фишек. По словам Линуса Торвальдса, все пока более-менее обычно. Первую половину патча составляют обновлённые и новые драйвера, а вторую — обновления архитектуры, документации и файловых систем.
Больше материалов в нашем корпоративном блоге и не только:
dimitrii_z
Интересно будет ли это как-то влиять на стабильность или иные показатели сети на домашних машинах? Судя по тексту вряд ли, фича чисто для дата-центров
artemlight
Рискну предположить, что существует ряд принципиальных ограничений. И самое главное - запрет фрагментации TCP-сегментов, означающий, что нижестоящие уровни модели OSI позволят надежно обмениваться сегментами такой длины.
В домашних условиях редкий свич умеет MTU выше 1600, так что будет по-старинке MSS 1460 без всякого вот этого. Да и скажем честно - ну вот даже 9к фреймы взять дома особо не откуда, разве что если у Вас только нет выделенного SAN сегмента для какой-нибудь лабы.
onegreyonewhite
Вы удивитесь как можно фоточками и домашними видосиками раскачать сетку, если дома поднять минисервер на TrueNAS/Openmediavault с zfs и кешами на ssd. Это вам не документооборот.
artemlight
Да можно и /dev/urandom по кругу гонять, и даже /dev/zero
Трунасы\медиаволты\тдтп это конечно хорошо, но ничего из этого не требует даже jumbo frames. Чтобы почувствовать какой-то буст, Вам как минимум понадобится какой-то кластер, low-latency свитч, FCoE\RoCE\RDMA\bla-bla-bla-capable сетевухи ну и некий ингресс, чтобы всё это в массы отдавать. Суммарная стоимость такого барахлишка выскочит по цене примерно как полторы-две квартиры, в которых снимались фоточки и видосики, так что целесообразность под вопросом.
Про нагрузку забыл. Гигабитный зырнет сейчас даже трехкопеечный арм в полку уводит, так что придётся либо делать кат6 вайринг, либо оптику кидать. Но самое забавное то, что обычный nvme ssd, зацепленный к usb4\thunderbolt положит всё это дело на лопатки в сценариях использования одним пользователем.
JPEGEC
Возникает вопрос, а в ДЦ то откуда такие пакеты? Они ж гоняют все теже фоточки и видосики.
Или ДЦ внутри себя инкапсулируют мелкие пользовательские пакеты в более крупные?
artemlight
Ну это маленько устаревшее видение.
Как правило, нарезка на сегменты "окончательного" размера происходит в самом конце, уже после SSL offload. До этого внутри приватных сетей может быть что хочешь и с каким угодно размером мту, лишь бы L1 позволял. А оно виртуальное процентов на 90 нынче, так что позволит хоть гигабайт, хоть три.
Когда я работал с 25\40G аплинками - мы решали достаточно очевидную, и в то же время сложную задачу. Банально - процессору не хватает гигагерц, чтобы индивидуально обрабатывать каждый приходящий пакет, насыщенный 25г линк может бодро кинуть вам на дата плейн 40 миллионов пакетов в секунду, и на их софтовый разбор останется около 100 процессорных тактов на пакет (и это - оптимистичный вариант). Приходится по-всякому кроить время - сначала ПЛИСина на сетевой карте занимается коннтрекингом и отправляет каждое соединение на конкретный TX\RX чейн (который привязан к определенному физическому ядру), потом через DMA все эти штуки попадают в кольцевые буфера - таким образом не нужно генерировать прерывание на каждый пакет и отрабатывать какое-то определенное количество пакетов за один чих.
А дальше начинается тёмная материя - например, чтобы сократить количество context switch из режима ядра в режим пользователя, стек TCP\IP выносится в юзерспейс целиком в контекст обслуживающего процесса, для него через mmap() из ядра вытаскивается тот самый кольцевой буфер сетевой карты, и всё это бодро крутится в юзерспейсе без дорогостоящих прыжков в ядро за новыми пакетами от сетевухи. Люто и весело, в общем.
И это 40г, а что там на 100г - я даже подумать боюсь. Но подозреваю, что там без балансировщика на входе делать нечего.
artemlight
Так вот увеличение размера пакета пропорционально снижает оверхед от операций декапсуляции TCP и в общем-то позволяет возвращать нормальную логику работы приложений (с прыжками в ядро за свежей информацией от сетевой карты). Насчет увеличения пропускной способности на 50% - мне сложно сказать, что они там меряли, но явно не в bandwidth упирались.
dimitrius86
да-к про дом-то речи нет.????????♂️ тут же датацентры.
ne-vlezay80
можно создать gre туннель поверх ipv4 с nopmtudisc ignore-df