Комментарии 11
Интересно будет ли это как-то влиять на стабильность или иные показатели сети на домашних машинах? Судя по тексту вряд ли, фича чисто для дата-центров
Рискну предположить, что существует ряд принципиальных ограничений. И самое главное - запрет фрагментации TCP-сегментов, означающий, что нижестоящие уровни модели OSI позволят надежно обмениваться сегментами такой длины.
В домашних условиях редкий свич умеет MTU выше 1600, так что будет по-старинке MSS 1460 без всякого вот этого. Да и скажем честно - ну вот даже 9к фреймы взять дома особо не откуда, разве что если у Вас только нет выделенного SAN сегмента для какой-нибудь лабы.
Да и скажем честно - ну вот даже 9к фреймы взять дома особо не откуда, разве что если у Вас только нет выделенного SAN сегмента для какой-нибудь лабы.
Вы удивитесь как можно фоточками и домашними видосиками раскачать сетку, если дома поднять минисервер на TrueNAS/Openmediavault с zfs и кешами на ssd. Это вам не документооборот.
Да можно и /dev/urandom по кругу гонять, и даже /dev/zero
Трунасы\медиаволты\тдтп это конечно хорошо, но ничего из этого не требует даже jumbo frames. Чтобы почувствовать какой-то буст, Вам как минимум понадобится какой-то кластер, low-latency свитч, FCoE\RoCE\RDMA\bla-bla-bla-capable сетевухи ну и некий ингресс, чтобы всё это в массы отдавать. Суммарная стоимость такого барахлишка выскочит по цене примерно как полторы-две квартиры, в которых снимались фоточки и видосики, так что целесообразность под вопросом.
Про нагрузку забыл. Гигабитный зырнет сейчас даже трехкопеечный арм в полку уводит, так что придётся либо делать кат6 вайринг, либо оптику кидать. Но самое забавное то, что обычный nvme ssd, зацепленный к usb4\thunderbolt положит всё это дело на лопатки в сценариях использования одним пользователем.
Возникает вопрос, а в ДЦ то откуда такие пакеты? Они ж гоняют все теже фоточки и видосики.
Или ДЦ внутри себя инкапсулируют мелкие пользовательские пакеты в более крупные?
Ну это маленько устаревшее видение.
Как правило, нарезка на сегменты "окончательного" размера происходит в самом конце, уже после SSL offload. До этого внутри приватных сетей может быть что хочешь и с каким угодно размером мту, лишь бы L1 позволял. А оно виртуальное процентов на 90 нынче, так что позволит хоть гигабайт, хоть три.
Когда я работал с 25\40G аплинками - мы решали достаточно очевидную, и в то же время сложную задачу. Банально - процессору не хватает гигагерц, чтобы индивидуально обрабатывать каждый приходящий пакет, насыщенный 25г линк может бодро кинуть вам на дата плейн 40 миллионов пакетов в секунду, и на их софтовый разбор останется около 100 процессорных тактов на пакет (и это - оптимистичный вариант). Приходится по-всякому кроить время - сначала ПЛИСина на сетевой карте занимается коннтрекингом и отправляет каждое соединение на конкретный TX\RX чейн (который привязан к определенному физическому ядру), потом через DMA все эти штуки попадают в кольцевые буфера - таким образом не нужно генерировать прерывание на каждый пакет и отрабатывать какое-то определенное количество пакетов за один чих.
А дальше начинается тёмная материя - например, чтобы сократить количество context switch из режима ядра в режим пользователя, стек TCP\IP выносится в юзерспейс целиком в контекст обслуживающего процесса, для него через mmap() из ядра вытаскивается тот самый кольцевой буфер сетевой карты, и всё это бодро крутится в юзерспейсе без дорогостоящих прыжков в ядро за новыми пакетами от сетевухи. Люто и весело, в общем.
И это 40г, а что там на 100г - я даже подумать боюсь. Но подозреваю, что там без балансировщика на входе делать нечего.
Так вот увеличение размера пакета пропорционально снижает оверхед от операций декапсуляции TCP и в общем-то позволяет возвращать нормальную логику работы приложений (с прыжками в ядро за свежей информацией от сетевой карты). Насчет увеличения пропускной способности на 50% - мне сложно сказать, что они там меряли, но явно не в bandwidth упирались.
да-к про дом-то речи нет.??♂️ тут же датацентры.
можно создать gre туннель поверх ipv4 с nopmtudisc ignore-df
Больше нововведений можно ожидать в последующих релиз-кандидатах.
Что?
Если кто не понял: к MTU и MSS это не имеет отношения. Входящие TCP пакеты склеиваются сетевым адаптером (но не все сетевухи такое умеют) вместе до максимального размера пакета, которое позволяет TCP протокол (сейчас 64K) и уже в таком виде передаются в user space: отсюда меньше пакетов, меньше переключений контекста меньше прерываний, а значит меньше загрузка cpu и быстрее. Аналогично, при отправке мы можем отправить tcp пакет 64K, а он сетевым адаптером нарежется на кусочки, которые позволяет физика (и размер mtu)
BIG TCP приходит в Linux — теперь и для IPv4