The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

В ядро Linux 6.8 приняты патчи, ускоряющие TCP, opennews (?), 14-Янв-24, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


1. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  –18 +/
Сообщение от Онанимоemail (?), 14-Янв-24, 10:01 
чудо на пасху, прям! неужели мейнтейнеры заглянули в сетевой стек линукса и увидели что там происходит! вау! браво!
Ответить | Правка | Наверх | Cообщить модератору

12. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +23 +/
Сообщение от Аноним (12), 14-Янв-24, 10:36 
Ты же не разработчик, да? Ты же не знаешь, что такое поддерживать и развивать большой проект и лезть в код критической подсистемы без явной нужды? Особенно с целью внесения такой не совсем очевидной оптимизации.
Ответить | Правка | Наверх | Cообщить модератору

13. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  –18 +/
Сообщение от DevOPS (?), 14-Янв-24, 10:38 
ну а к чему тут ваши оправдания?
Ответить | Правка | Наверх | Cообщить модератору

35. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +2 +/
Сообщение от Аноним (35), 14-Янв-24, 11:04 
девопсы не нужны
Ответить | Правка | Наверх | Cообщить модератору

92. Скрыто модератором  +2 +/
Сообщение от Аноним (-), 14-Янв-24, 13:47 
Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

210. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +/
Сообщение от Пряник (?), 15-Янв-24, 11:13 
А что мешает протестировать изменения?
Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

75. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +2 +/
Сообщение от Аноним (75), 14-Янв-24, 13:07 
Ой, а расскажи, что там происходит? Давай, ты ведь так уверенно говоришь. Со ссылками на конкретные строчки, ага.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

112. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +4 +/
Сообщение от ptr (??), 14-Янв-24, 14:26 
Есть вполне обоснованное предоложение, что подобная оптимизация заметна только при маршрутизации 100 гигабит и выше. В противном случае, в промежутке между пакетами выполнится достаточно кода, чтобы эти данные оказались вытеснены из кеша.
Отсюда, надобность в подобной оптимизации возникла недавно и востребована для довольно узких областей применения. При типовой нагрузке (сервер приложений, СУБД и т.п.) эти 40% легко могут превращаться в тыкву.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

121. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +2 +/
Сообщение от Аноним (121), 14-Янв-24, 15:14 
> Есть вполне обоснованное предоложение, что подобная оптимизация заметна только
> при маршрутизации 100 гигабит и выше.

А зачем маршрутизатор TCP трогать полез в таком объеме вообще? А кроме типовых вон тех есть еще типовые - сервера статики допустим - где TCP завались, отгрузка на скорость мастхэв, и там как раз никакой тыквы, все как надо будет.

Ответить | Правка | Наверх | Cообщить модератору

128. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +2 +/
Сообщение от ptr (??), 14-Янв-24, 17:04 
> А зачем маршрутизатор TCP трогать полез в таком объеме вообще?

Потому что 100 гигабитный Ethernet стал дешевым и доступным. Тот же LR-Link LRES1019PF-QSFP28 на Intel E810 уже дешевле $500 стал стоить, что даже для SOHO рынка доступно. Поэтому проблему с маршрутизаторами на Linux потребовалось решать.

> сервера статики допустим - где TCP завались

Елси не гигабайты видео отдаются, то там TCP совсем немного. Только на обработке HTTP данные будут вытесняться из кеша CPU. Не говоря уже об издержках FS.

Ответить | Правка | Наверх | Cообщить модератору

152. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +/
Сообщение от penetrator (?), 14-Янв-24, 19:50 
Mellanox ConnectX-6 HDR 200Gb Adapter QSFP56 - 519 USD

жаль их нвидиа купила

Ответить | Правка | Наверх | Cообщить модератору

161. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +/
Сообщение от Аноним (-), 14-Янв-24, 22:35 
> Потому что 100 гигабитный Ethernet стал дешевым и доступным. Тот же LR-Link
> LRES1019PF-QSFP28 на Intel E810 уже дешевле $500 стал стоить,

Да нет, это то все круто, а TCP зачем роутером трогать? Роутеру в его нормальном виде вообще класть TCP там, UDP или что еще, он это может даже не парсить.

Вон то скорее для серверов статики пригодится.

> Елси не гигабайты видео отдаются, то там TCP совсем немного.

Серваки разные бывают. Всякие картинки, видео и проч хомячки генерят терабайтами, так что там перфоманса много не бывает.

> Только на обработке HTTP данные будут вытесняться из кеша CPU. Не говоря уже об издержках FS.

Сейчас IO и RAM быстрые. Да и кеши разжирели.

Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

171. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +/
Сообщение от ptr (??), 14-Янв-24, 23:17 
> Да нет, это то все круто, а TCP зачем роутером трогать?

Речь не о домашних роутерах, а о тех случаях, где маршрутизация L4 необходима.

> для серверов статики пригодится

Там мелкого neper tcp_rr хватило, чтобы из 105 МБ L3 кеша все вылетело. Какой тут nginx? Для него и гигабайта кеша не хватит.

Ответить | Правка | Наверх | Cообщить модератору

127. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  –1 +/
Сообщение от Аноним (127), 14-Янв-24, 17:04 
Роутинг 100 гбит/с процессором общего назначения с линуксом? Чего только на опеннете не прочитаешь!
Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

132. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  –1 +/
Сообщение от ptr (??), 14-Янв-24, 17:15 
А Вы что думаете, что всяческие MicroTik, QTech, DLink и т.п. с 100GbE QSFP28 не на базе ядра Linux? Тот же RouterOS в открытую заявляется, что на ядре Linux.
Ответить | Правка | Наверх | Cообщить модератору

198. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +/
Сообщение от Full Master (?), 15-Янв-24, 06:26 
Обычно в таком случае используется DPDK.
Ответить | Правка | Наверх | Cообщить модератору

200. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +/
Сообщение от ptr (??), 15-Янв-24, 07:34 
Который собирается, в том чиссле, из кода ядра Linux и NIC драйверов, который представлен в обсуждаемом патче.
Ответить | Правка | Наверх | Cообщить модератору

211. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +/
Сообщение от Пряник (?), 15-Янв-24, 11:16 
Мне кажется в какой-то момент маршрутизацию делает на железе, а не программно. И изначальный автор комментария подразумевал это.
Ответить | Правка | Наверх | Cообщить модератору

217. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +/
Сообщение от ptr (??), 15-Янв-24, 12:43 
Не исключаю, что, например, CISCO так и делает где-то. Но мы все же про Linux речь ведем. Offload маршрутизации Linux точно не поддерживает. Да я даже не понимаю, в чем смысл маршрутизации в NIC, так как в подавлющем большинстве случаев маршрутизация выполняется между NIC.
Ответить | Правка | Наверх | Cообщить модератору

308. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +/
Сообщение от Аноним (307), 19-Янв-24, 15:31 
> Мне кажется в какой-то момент маршрутизацию делает на железе, а не программно.
> И изначальный автор комментария подразумевал это.

В лине с неких пор есть подсистемы управления свичами и хардварного оффлоада.

Ответить | Правка | К родителю #211 | Наверх | Cообщить модератору

136. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +/
Сообщение от Аноним (136), 14-Янв-24, 17:57 
Можешь профайлером посмотреть сколько и какой код проводит в ядре при нагрузке и увидеть, что и без 100GBit/sec нагрузка в ядре заметна. Тем более пакет обрабатывает не одна ф-я в сисколе между юзерсвпейным кодом. Рассуждения подобного рода совершенно бессмысленны из общих соображений.
Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

149. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +/
Сообщение от ptr (??), 14-Янв-24, 19:25 
> пакет обрабатывает не одна ф-я

В том то и дело, что при сложной маршрутизации, множестве правил firewall и еще с QoS, что типично для маршрутизаторов, экономия кеша CPU станет заметной. Но при типовой нагрузке endpoint сервера, количество обращений в ядре к оптимизированным в патче для кеширования CPU данным падает на порядок. И реальный выигрыш вряд ли превысит 4%.

Ответить | Правка | Наверх | Cообщить модератору

137. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +/
Сообщение от Аноним (136), 14-Янв-24, 18:06 
Там же, кстати, в тесте рассказано как тестировали, однин из типичных сценариев RPC/сервиса. Конечно, 40% получишь не всегда. Из их же тестов, в условиях нехватки кеша улучшения порядка 1-2 %
Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

153. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +1 +/
Сообщение от ptr (??), 14-Янв-24, 19:52 
> Из их же тестов, в условиях нехватки кеша улучшения порядка 1-2 %

Именно про это речь и веду. Чем больше кода в userspace, тем скорее не хватит кеша.
С минимальным кодом в neper tcp_rr и 256Mb L3 cache они получили аж до 44.47%. Но с тем же кодом уже на 105Mb L3 cache - не более 5.24%. Поставьте хотя бы тупейший gRPC сервис (вроде примера WeatherForecast из InMemory DB) вместо neper и 256Mb L3 тоже не хватит.

Ответить | Правка | Наверх | Cообщить модератору

187. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +/
Сообщение от Аноним (136), 15-Янв-24, 00:52 
Ты ведёшь речь о том, что кеша точно не хватит. Чувствуешь же зарницу?

> Поставьте хотя бы тупейший gRPC сервис (вроде примера WeatherForecast из InMemory DB) вместо neper и 256Mb L3 тоже не хватит.

Ну не неси чушь. Видимо, разницу не чувствуешь. Хватит или нет зависит от приложения.

Ответить | Правка | Наверх | Cообщить модератору

195. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  –1 +/
Сообщение от ptr (??), 15-Янв-24, 05:23 
> Ну не неси чушь.

Спасибо, что признали свое полное поражение в дискуссии, перейдя на личности

> Хватит или нет зависит от приложения.

Вот именно. Ровно то, что я и написал:
> Поставьте хотя бы тупейший gRPC сервис (вроде примера WeatherForecast из InMemory DB) вместо neper и 256Mb L3 тоже не хватит.

И это будет в несколько раз большая нагрузка на кеш L3, по сравнению с neper tcp_rr

Ответить | Правка | Наверх | Cообщить модератору

197. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +1 +/
Сообщение от Аноним (136), 15-Янв-24, 05:39 
Не, это ровно не то, что ты написал. Приводишь ровно один пример приложения, утверждаешь что на нём ничего хорошего заметно не будет и __обощаешь__ этот пример на все приложения. Вот что конкретно ты делаешь. Оставляя единственный вариант 'оптимизация заметна только при маршрутизации'. И это ахинея. Потому что а) не все gRPC приложения как пишешь выше и даже в твоих условиях нагрузка на кеш будет зависеть от реализации. Самый тупой пример хорошей реализации твоего конкретно gRPC это простое кеширование топ-N ответов что уложит основной горячий след по памяти в жирный кеш. Даже и не в жирный. Да даже вся эта InMemoryDB для прогнозов зайдёт в кеш целиком.
Ответить | Правка | Наверх | Cообщить модератору

201. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  –1 +/
Сообщение от ptr (??), 15-Янв-24, 07:36 
> И это ахинея

Еще раз спасибо, что публично признали себя демагогом.

Ответить | Правка | Наверх | Cообщить модератору

202. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  –1 +/
Сообщение от ptr (??), 15-Янв-24, 07:55 
> даже вся эта InMemoryDB для прогнозов зайдёт в кеш целиком

Там в примере три или четыре прогноза, так что не в этом проблема. Проблема в мегабайтах кода нескольких десятков нитей с собственным стеком и ворохом создаваемых объектов, включая семафоры, которые только на сериализации и десериализации ProtoBuf уже сожрут любой кеш CPU.
Просто скомпилите этот пример https://learn.microsoft.com/en-us/aspnet/core/tutorials/firs...
Потом грузаните его хотя бы на 32-х ядрах, как делал я. И сами увидите, что кеш CPU вытесняется в userspace полностью.
Можете брокер Кафки поднять на тех же 32-х ядрах и с тем же ProtoBuf. Эффект тот же самый увидите.

> __обощаешь__ этот пример все приложения

Потому что проще него придумать, что-то имеющее хоть какую-то практическую ценность, уже мало реально. Теоретически, можно написать сервис на C + ассемблер, сократив нагрузку на кеш CPU. Но на практике финансировать такую разработку будут только в редчайших случаях, о чем я и указал, приведя в качестве примера разработку маршрутизаторов.

Ответить | Правка | К родителю #197 | Наверх | Cообщить модератору

218. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  –1 +/
Сообщение от Аноним (136), 15-Янв-24, 14:57 
Это, конечно, хорошо, что знаешь столько умных слов, но попробуй всё же услышать что тебе пишут: натягиваешь свой единственный пример на все случаи жизни. Не понимаю в чём проблема понять такую простую и очевидную истину.

> Tutorial: Create a web API with ASP.NET Core

Это даже не смешно ... Затрудняюсь даже прокомментировать такой уровень глупости

> Но на практике финансировать такую разработку будут только в редчайших случаях,

Сервисы на c++ пишут повсеместно, в частности с gRPC и другими RPC

> ... о чем я и указал, приведя в качестве примера разработку маршрутизаторов.

Код, задействованный для маршрутизации, не тот же самый код, который используется в реализации TCP сокетов. Этот патч вообще никак не пересекается с маршрутизацией, он целиком для приложений.

Ответить | Правка | Наверх | Cообщить модератору

232. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +/
Сообщение от ptr (??), 15-Янв-24, 23:30 
> такой уровень глупости

Комментарии излишни )))
Вы уже трижды доказали, что Вы демагог!

Ответить | Правка | Наверх | Cообщить модератору

233. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  –1 +/
Сообщение от Аноним (233), 16-Янв-24, 00:20 
>> такой уровень глупости
> Комментарии излишни )))
> Вы уже трижды доказали, что Вы демагог!

По моему ржать тут стоит с додика с доднетом который ему видите ли кеш вытеснил. Бжа, это вы там с майкрософтом отношайтесь на эту тему. Тут вы что забыли? Вам с сабжа вообще нихрена не обломится.

Ответить | Правка | Наверх | Cообщить модератору

296. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +/
Сообщение от ptr (??), 19-Янв-24, 03:43 
Ржать тут можно с джуна, пытающегося на C++ писать сервисы, где без глубокой рефлексии с компиляцией кода при работе сервиса не обойтись, не уходя в глубокие тормоза или не перекомпилируя вообще весь проект при любой изменении схемы в регистре )))
Ответить | Правка | Наверх | Cообщить модератору

297. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  –1 +/
Сообщение от Аноним (-), 19-Янв-24, 04:15 
> Ржать тут можно с джуна, пытающегося на C++ писать сервисы, где без
> глубокой рефлексии с компиляцией кода при работе сервиса не обойтись, не
> уходя в глубокие тормоза или не перекомпилируя вообще весь проект при
> любой изменении схемы в регистре )))

Ваш экспериенс с дотнетом все же врядли релевантен - это здоровенный интрузивные рантайм, который к тому же крайне редко используется в пингвине. Поэтому экстраполировать такой опыт на совсем другой кейс - и еще наезжать кто тут джун - выглядит довольно специфично со стороны, я б сказал. И уж как минимум я точно не буду доверять таким данным всерьез. Ибо 50/50 что окажется на самом деле какими-нибудь виндодотнетопроблемами и - вот - самоуверенным НеДжуном экстраполировавших их на весь мир.

Ответить | Правка | Наверх | Cообщить модератору

310. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +/
Сообщение от ptr (??), 19-Янв-24, 20:10 
В том то и прикол, что Вы откровенно занимаетесь демагогией, даже не попытавшись ответить на вопрос, как писать gRPC сервисы на C++, если сервисов сотни, схемы все реестре и используются еще и для сотен топиков Confluent. На практике, тут выбор заканчивается между JVM и CIL. И то и другое замечательно живет в Linux под k8s. Но темпы развития Java за последние годы существенно уступают темпам развития C#, что и склоняет в его сторону.
Если Вы даже попробуете перекомпилировать сотни сервисов на C++ при каждом изменении версии схемы protobuf в реестре, то убедитесь, что тот ворох кода, который генерирует protoc, включая связанные с ним классы, очень незначительно уступает по объемам аналогичным сборкам для JVM или CIL.
Судя по Вашему догматизму, Вам исключительно недостаток опыта не позволяет признать, что есть области применения, где рефлексия может дать намного больший прирост производительности, чем отказ от JIT и GC.
Ответить | Правка | К родителю #297 | Наверх | Cообщить модератору

181. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +/
Сообщение от лютый жабби.... (?), 15-Янв-24, 00:18 
>только при маршрутизации 100 гигабит и выше

открою страшную тайну.... цифирь на порядки ниже. берем постфикс и его флудилку, балуемся с размерами писем и видим, что постфикс не может 100 МЕГАБИТ прокачать...

и дело не в постфиксе, делал простейшую прогу с голыми сокетами, на больших посылках и гигабит и 100мбит прокачивается легко, а делаешь размер "пакетов" 5КБ, то 100 мегабит/сек уже трудно получить.

Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

188. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +/
Сообщение от Аноним (136), 15-Янв-24, 00:57 
1 Gbit/sec вообще легко забивается: 5кб пакет это примерно 25к RPS для 1 Gbit/sec, детские числа
Ответить | Правка | Наверх | Cообщить модератору

196. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +/
Сообщение от ptr (??), 15-Янв-24, 05:37 
Что Вы называете "пакетом"? Если размер данных в одной TCP сессии, то Вы вовсе не пропускную способность измеряете. Берите neper tcp_rr и им измеряйте.
Ответить | Правка | К родителю #181 | Наверх | Cообщить модератору

249. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +/
Сообщение от лютый жабби.... (?), 16-Янв-24, 10:03 
>Что Вы называете "пакетом"? Если размер данных в одной TCP сессии, то Вы вовсе не пропускную способность измеряете

Многопоточное приложение. каждый поток открывает сокет, шлет Х килобайт, закрывает сокет.
При Х==5 начинает очень хорошо жрать CPU (несколько ядер) при потоке 1гбит.

Выше речь была про то, что установка соединения не важна.... важна, получается. Что ещё может проц жрать?

Ответить | Правка | Наверх | Cообщить модератору

298. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +1 +/
Сообщение от Аноним (-), 19-Янв-24, 04:24 
> Многопоточное приложение. каждый поток открывает сокет, шлет Х килобайт, закрывает сокет.
> При Х==5 начинает очень хорошо жрать CPU (несколько ядер) при потоке 1гбит.

Чувак, ты оправдываешь свой ник. Устроил почти SYN-флуд и еще удивляешься. Твой уровень технологий это гребаный стыд уровня HTTP/1.0 по смыслу. Который так то вымер - за дело.

По нормальному либо шлют несколько запросов в одной конекции, либо UDP юзают, чтоли. Хотя с всеми наворотами типа fastopen можно попытаться, но TCP в общем то не для настолько отшибленого использования делался.

> Выше речь была про то, что установка соединения не важна.... важна, получается.
> Что ещё может проц жрать?

Если оно еще и шифрованое - согласование ключей, например. А так - профайлер да не в моде? Ты какой-то совсем неправильный жабист, они зеленеть в профайлерах любят. Ну хоть perf top, не, неужто обжор не показывает? Хотя можно конечно погадать на кофейной гуще вместо инструментированых измерений.

Ответить | Правка | Наверх | Cообщить модератору

234. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +/
Сообщение от Аноним (233), 16-Янв-24, 00:22 
> и дело не в постфиксе, делал простейшую прогу с голыми сокетами, на
> больших посылках и гигабит и 100мбит прокачивается легко, а делаешь размер
> "пакетов" 5КБ, то 100 мегабит/сек уже трудно получить.

100Мбит сетевки обычно ничего кроме стандартных 1500 байтовых пакетов не умеют. Вот хоть там как. Jumbo - привилегия гигабита, и то работает только локально как правило.

Ответить | Правка | К родителю #181 | Наверх | Cообщить модератору

120. "В ядро Linux 6.8 приняты патчи, ускоряющие TCP"  +4 +/
Сообщение от Аноним (121), 14-Янв-24, 15:12 
> чудо на пасху, прям! неужели мейнтейнеры заглянули в сетевой стек линукса и
> увидели что там происходит! вау! браво!

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

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру