[dazgluk]

Не понял этой вашей фразы. Вы тоже согласны, что глупо что-то переписывать ради микро профита? Это как раз о lisg.

А что такое линейное масштабирование софта? Вы же хотите полку чуть-чуть отодвинуть оптимизацией и все, не называл бы это линейной масштабируемостью.

Глупо переписывать весь сетевой стек, когда стоимость сервера ~ 150$ за гигабит полосы. Лишь бы софт вел себя предсказуемо на 1Gb/s, 2Gb/s, 10Gb/s, 20Gb/s, 50Gb/s и линейно кушал ресурсы в зависимости от нагрузки, и это как раз таки не то, что мы видим в LISG.

на ~ 7Gb/s трафика, он ведет себя нормально, а дальше начинается лавинообразный рост нагрузки CPU, предположительно связанный с локами, именно это и хочется "отодвинуть"

 

Шейпер, полисер, классификатор, нэтфлоу и даже НАТ - это задачи, где сетевой стэк ОСи как бы и не нужен совсем. Пространство для оптимизаций просто огромное.

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

Нас вполне устраивает как работает линуксовый сетевой стек, устраивает как работает conntrack, устраивает как работает ipt_netflow...

Проблема только в LISG, а именно в том, что он вероятнее всего начинает дедлочится на определенном трафике, и именно этот небольшой кусочек и хочется переделать.

 

Хотя, учитывая что за сутки, Вы единственный кто отписал в теме хотя бы что-то, по видимому стоит начинать писать с нуля, посмотрим, может у arni что-то получится

[ttttt]

Лишь бы софт вел себя предсказуемо на 1Gb/s, 2Gb/s, 10Gb/s, 20Gb/s, 50Gb/s и линейно кушал ресурсы в зависимости от нагрузки, и это как раз таки не то, что мы видим в LISG.

Такого софта в природе не существует, потому что процессор абсолютно нелинейное устройство.

 

Из 7 Gb/s при переписывании lisg ну может 10 Gb/s получится, и это в лучшем случае. Проблема не в нем, проблема во всем зоопарке ВМЕСТЕ.

[Igor Diakonov]

Из 7 Gb/s при переписывании lisg ну может 10 Gb/s получится, и это в лучшем случае. Проблема не в нем, проблема во всем зоопарке ВМЕСТЕ.

Вроде как речь идёт о решении вполне конкретной задачи - промолотить при нужном наборе софта 10Гбит/сек на одной машине.

Вы хотите что-то конкретное предложить для её решения или же вам просто скучно в пятницу?

[ttttt]

Вообще-то речь идет вон аж о 50 Gb/s. Я в состоянии пооптимизировать lisg, но считаю задачу идиотской, на что и обратил внимание автора. Но раз автору виднее, то пусть сам решает.

[dazgluk]

50Gb/s было для красного слова, если честно, задача - сделать так, чтобы он не ложился при 10gb/s, а ещё лучше 20gb/s full-duplex. Вот Вы так хаете LISG, а есть ли хоть что-то хотябы более-менее альтернативное?

[ttttt]

задача - сделать так, чтобы он не ложился при 10gb/s

Заведите больше серверов - станет меньше трафика на сервер и не будет ложиться при суммарном 10 Gb/s.

 

а ещё лучше 20gb/s full-duplex

Ну вот, о чем и говорю. Не достижимо это на текущем софте, он принципиально неправильный с точки зрения производительности.

Изменено 17 апреля, 2015 пользователем ttttt

[pavel.odintsov]

Лишь бы софт вел себя предсказуемо на 1Gb/s, 2Gb/s, 10Gb/s, 20Gb/s, 50Gb/s и линейно кушал ресурсы в зависимости от нагрузки, и это как раз таки не то, что мы видим в LISG.

Такого софта в природе не существует, потому что процессор абсолютно нелинейное устройство.

 

Из 7 Gb/s при переписывании lisg ну может 10 Gb/s получится, и это в лучшем случае. Проблема не в нем, проблема во всем зоопарке ВМЕСТЕ.

 

Поддерживаю всецело. Завалить тот же ipt_netflow легким флудом из hping - домашнее упражнение для первоклассников. DPDK все это решает, но ценой отказа от всего стека Linux :)

[ttttt]

Как по мне, провайдерам нужно определяться, в каком направлении они собираются развиваться:

1) горизонтально: недорогие слабые машинки с гигабитными, может даже десятигигабитными интерфейсами воткнутые в коммутаторы с парой интерфейсов потолще, зато на уже готовом старом неоптимальном софте;

2) менее горизонтально, больше вертикально: 20, 40, 100 гигабит, но о готовом старом софте в ядре пора забывать, его никто не будет оптимизировать в ядре под такие нагрузки, нужно смотреть на новый, вкладывать в новый;

Изменено 24 апреля, 2015 пользователем ttttt

[SyJet]

Лишь бы софт вел себя предсказуемо на 1Gb/s, 2Gb/s, 10Gb/s, 20Gb/s, 50Gb/s и линейно кушал ресурсы в зависимости от нагрузки, и это как раз таки не то, что мы видим в LISG.

Такого софта в природе не существует, потому что процессор абсолютно нелинейное устройство.

 

Из 7 Gb/s при переписывании lisg ну может 10 Gb/s получится, и это в лучшем случае. Проблема не в нем, проблема во всем зоопарке ВМЕСТЕ.

 

Поддерживаю всецело. Завалить тот же ipt_netflow легким флудом из hping - домашнее упражнение для первоклассников. DPDK все это решает, но ценой отказа от всего стека Linux :)

Только вот никто не пишет под dpdk, вот у Арни новый и интересный продукт, но тоже ванильный.

[arni]

на LISG большая архитектурная проблема - сама структура данных и методы блокировок. Мы в свое время пытались ее улучшить, но в результате плюнули и стали писать с нуля.

Однако, 50Gbit сегодня вполне перевариваемый софтом трафик. На TileGX процессорах можно добиться очень приличного перформанса - особенно на 72-ядерном. Мы тоже наш софт под эту платформу собирали без проблем, единственная проблема - цена решения уже сравнима с Juniper MX для первого проекта (лицензии). Хотя если растрясти Mikrotik на драйвера к их железкам - очень даже можно сделать красивое решение. Но микротиковцы жадные - даже GPL нарушают

[ttttt]

На TileGX процессорах можно добиться очень приличного перформанса - особенно на 72-ядерном. Мы тоже наш софт под эту платформу собирали без проблем

Собирать-то, собирали, а перформанс не тестировали? А то микротик вон тоже собирает, но даже гигабит пока проблема на таких задачах :D У них вроде только MPLS пооптимизирован под тилеры, но могу ошибаться.

Изменено 25 апреля, 2015 пользователем ttttt

[arni]

В том то и дело, что Tilera на потрогать железки не дает, а на микротике нет драйверов (точнее, они что-то нахимичили со стандартными и не признаются что).

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

Мы изначально целились на многоядерную параллельную обработку и строили под это архитектуру, так что потестить на 36 или 72 ядрах для нас очень соблазнительно :D

Мы делали тесты на 7 Gbit - загрузка в пределах 2-7% на всех ядрах, но пока не нашли возможность протестировать на большем трафике :(

[SABRE]

А accel-ppp такой проблемой не страдает? там вроде то-же сделано нативными для системы методами.

[arni]

судя по коду, accel-ppp скорее всего не очень хорошо маcштабируется от количества ядер. Плюс еще и пакеты в юзерспейс кидаются, что тоже не есть гуд. было бы кстати интересно провести тесты, сравнить и выложить результаты - при выборе решения всегда полезно

[ttttt]

А я вот уверен, что решение arni не будет сильно отличаться по производительности ни от решений с accel-ppp, ни от решений с lisg.

[arni]

А я вот уверен, что решение arni не будет сильно отличаться по производительности ни от решений с accel-ppp, ни от решений с lisg.

За accel-ppp не скажу, не внедряли и не тестили. Но LISG жрет CPU значительно сильнее чем USPE. При тех же требованиях к конфигу, том же железе и трафике : LISG 30-40% сpu, USPE - 2-5%.

Это при трафике около 5Gbit/s, в районе 450Kpps и около 8K сессий. Железо - I7, 3.5Ghz, 4 ядра, 10Gbit Intel LAN.

Если есть внедренный accel-ppp, был бы рад сравнить скорость с таким же конфигом для USPE. Правда, все-таки хотелось бы сравнивать сравнимые вещи - когда допишем наконец IP-unnumbered и DHCP-relay в USPE.

[ttttt]

Ну 2-5% означает, что ни во что не упирается, 30-40% - упирается. И это все, что оно означает. Меряться этим абсолютно бессмысленно на данных задачах.

Сравнивать надо целиком решение.

Изменено 26 апреля, 2015 пользователем ttttt

[SABRE]

Плюс еще и пакеты в юзерспейс кидаются,

Ну естественно кидаются - ДХЦП юзеру на основе чего выдавать? Трафик, конечно, ходит нативными для ядра путями без юзерспейса.

Изменено 26 апреля, 2015 пользователем SABRE

[arni]

Ну 2-5% означает, что ни во что не упирается, 30-40% - упирается. И это все, что оно означает. Меряться этим абсолютно бессмысленно на данных задачах.

Сравнивать надо целиком решение.

Именно решение в указанном случае и сравнивали. Как раз и получается что на той же самой задаче LISG сильно проиграл в производительности.

[arni]

Ну естественно кидаются - ДХЦП юзеру на основе чего выдавать? Трафик, конечно, ходит нативными для ядра путями без юзерспейса.

Я так понял еще и пакеты создающие сессию. Вообще context-switch на рутере это плохо, мы релей ядерный пишем

[kayot]

Ну естественно кидаются - ДХЦП юзеру на основе чего выдавать? Трафик, конечно, ходит нативными для ядра путями без юзерспейса.

Я так понял еще и пакеты создающие сессию. Вообще context-switch на рутере это плохо, мы релей ядерный пишем

А если посчитать? Средний pps при канале 1Г нынче 200-300к.

1Г это ~1k пользователей онлайн(грубо). В нашей схеме dhcp-лиза выдается на 5 минут, значит раз в 2.5 минуты идет обновление, 1 пакет запрос, 1 ответ.

Итого имеем 1000/2.5/60=6.6(!!!) dhcp-запросов в секунду.

Сравниваем ppp данных(200к) и pps dhcp(7 пакетов), понимаем что собака зарыта не там.

[ttttt]

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

Это все неизбежно оптимизировать после 10г.

 

Материалы по теме, хоть уже постил, но вдруг кто-то не видел:

LWN: Jonathan Corbet: Improving Linux networking performance (2015)

Adrian Chadd: Intel DDIO, LLC cache, buffer alignment, prefetching, shared locks and packet rates. (2015)

The Power of Batching in the Click Modular Router (2012)

Изменено 26 апреля, 2015 пользователем ttttt

[arni]

я сразу написал, что проблема LISG в архитектуре, а accel-ppp мне нужно протестировать. Сам принцип кидать пакеты в юзерспейс потенциально вектор для DoS. Поэтому пока все хорошо - это не влияет. Но когда плохо - может подкинуть проблем. Постараюсь поскорее протестировать в схожих условиях, а то выходит много философии и мало цифр :)

 

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

Это все неизбежно после 10г.

читаете мысли :)

[aabc]

Завалить тот же ipt_netflow легким флудом из hping - домашнее упражнение для первоклассников.

Сколько же негатива, и всё потому что у вас 4 года назад что-то крашнулось.

[pavel.odintsov]

Завалить тот же ipt_netflow легким флудом из hping - домашнее упражнение для первоклассников.

Сколько же негатива, и всё потому что у вас 4 года назад что-то крашнулось.

 

Оно и сейчас валит машину, просто надо чуточку более постараться - влейте в машину, на которой работает ipt_netflow килоппс 500 флуда (hping3 подойдет) сильно рандомного и посмотрите, сколько ядер уйдет в полку и что произойдет с роутингом. Это - мина замедленного действия, если бы роутер стоял "без побрякушек" он бы провернул несколько миллионов пакетов/секунду играючи и пережил ЧНН.

 

Не стоит думать, что мой негатив не имеет под собой оснований, он идеологический - я не согласен с используемым подходом.

 

Но я все равно очень благодарен за тулкит, так как netflow генерируется качественный и согласно всем спецификациям. Я отлично протестировал им свой софт, пока писал парсеры. Вопрос лишь в том, что подходит он для довольно слабо нагруженных сетей и об этом стоит писать явно.

Изменено 2 мая, 2015 пользователем pavel.odintsov