Сделать что-то в процессоре общего назначения, что пролезет через тесты, не просто легко, а очень легко — коверейдж возможных состояний настолько мал, что на фабрике можно налепить что угодно, что пройдет инспекцию «визуальной» топологии. Собственно, поэтому дроч на всякие гнутые инициативы в стиле «запихни корбут вместо стоковой фирмвари в x86-тушку и будь единоличным владельцем своей пеки» остается дрочем, а не идет в массы. Если говорить об одноочередном однотредовом ядре без d/i кеша (или иной контролируемой неявно сущности, влияющей на execution flow), то покрытие можно осуществить софтом и тут да, можно говорить об отсутствии закладок. Интересы у вояк, впрочем, будут в основном в жирных плисах, которые, опять же, имеют так много стейтов, что ни в какое реальное время даже на физической железке их покрыть не выйдет, то есть переход, открывающийся хаммерингом по какой-то последовательности инструкций и меняющий privilege level, скорее суровая реальность, чем выдумка.
Можно сделать довольно хороший FIB из большого (не настольного, типа фенома) SEM с высокой энергией пучка. Стоить это будет для RU непонятно сколько, для штатов/европы <20k$. Посмотри на проект NPGS еще, если интересна эта переделка.
Про опенсвич и акктоны клялись, что там бродкомовская прослойка таки будет открыта на уровне посмотреть. Если так, то кванта получила очень серьезную конкуренцию :)
> Текущие реализации OVS и его портов типа Pica8 требуют костылей со стороны
контроллера, что повышает трудозатраты (разработчиков и инженеров) и
прозрачность кода.
Гм, там вроде нет особенных костылей, если не говорить именно про пику.
> Ну и изначально ориентируемся на легкий framework для baremetal с версией для x86
серверов.
Тем не менее, фоллбекать процессинг на менеджмент энжин, при отсутствии возможности сделать требуемое матрицей, вы будете или вместо этого ограничите возможности стандарта per-матрица?
BTW выше вы с Игорем имеете в виду разные чейнинги.
Ну ONS насколько мне известно забил на софтовую платформу и делает упор на апи матрицы, а овс, когда я там его тестировал, был очень глючным. Вообще идея втыкать of-правила в матрицу, казавшаяся очень привлекательной два года назад, продолжает разбиваться о фактические возможности недорогих матриц — затруднена цепочечная группировка правил в нужных масштабах, много чего в железе просто не поддерживается и тд. Кумулюс года полтора назад казался достаточно провальным с его тогдашними объемами поддержки железа, а сейчас напротив — ONIE сертифицировался на большом числе железок, на него же подтянулась pica и будущее кажется довольно неплохим, плюс ребята реально много делают плюшек в хост-стеке. Pica же, напротив, с текущими тенденциями развития матриц не имеет, на мой взгляд, прорывного будущего. Втыкать полную спецификацию OF в обычный ToR-девайс очень сложно и избыточно, поскольку ему надо правил порядка 1..10 * число портов как максимум, а процессинг трафика лучше распределять по софтсвичам на вычнодах. На абсолютную истину мои высказывания не претендуют, просто развитие матриц все сильнее корректирует взгляды на то, как это все должно (будет) работать.
>> Ну и попутно framework для наших партнеров по коммутаторам
Не совсем понятно — у коммутаторов обычно софтверный датапэс как класс отсутствует, я даже сходу не могу привести обратный пример. Или все же речь про общий апи?
А инициатива по классификаторам OF в tc вам не кажется более привлекательной? Менять овс можно либо на чистый юзерспейс, либо на них, в общем-то (как кажется). И какие в первую очередь задачи преследуете?
Каким образом формируется цена на эмулируемое хранилище, A*Объем + B*IOPS + C? Было бы интересно узнать стоимости для определенных конфигураций, потому что здесь цена ssd усиливается ценником самой схд, также космической.
Насыщение очереди /32м флудом после докручиваний наступает в районе 495kpps, если выставить рейт 485, то все ок, если 490 или 493 — флоу контроль начинает дергаться и летят софт локапы. Иными словами, любой фильтрующий сины инстанс на линуксе сейчас можно подвесить достаточно дешевой атакой, достаточной для забивания одной очереди карты. Другое дело, что одинокий трансмиттер легко забанить, а флуд со многих ничем не отличается от обычной «теоретической» атаки на синпрокси, так что проблема вряд ли принадлежит к кругу реальных.
Коннтрек в линуксе к сожалению обрушивается при флуде с нулевого порта в условиях насыщения очередей :) Давеча писал в нетдев, пока что-то никто не ответил. Касательно HT в другой цепочке — да, отключать его надо всегда.
Нуу 3.23.2.1 как раз его чинит, в дмесге это видно. До него последний рабочий кажется 3.17. 4ка по кодовой базе очень мало отличается, так что она вряд ли даст какое-то улучшение. Для обработки, если не упираться в процессор и выделить изолированные ядра для юзерспейса, чтобы процессить трафик, показательно что-то в районе 12.6Mpps/карта. Потолок также зависит от конкретного процессора — например, идентичные настройки и идентичная платформа для 2620v2 и 2603v2 дают больший результат для второго, если у первого, имеющего большую частоту и большее число ядер, включен гипертрединг.
Да, я имел в виду обработку, то есть все, отлично от pkt-gen -f rx и бриджа. 10, соответственно, с отключенным турбо и зафиксированными частотами, включенным dca, и разбросанными прерываниями? // 3.23.2 еще был сломан, в .1 как раз дофиксили DCA.
А сколько на этой версии драйвера получается выжать на одной карте на 60b пакетиках на сабжевой корке? В более ранних сломан DCA, поэтому там может быть печаль, а односокетные системы интересны тем, что не дают лайн рейта ни при каких ухищрениях на насыщении пакетами.
Ну, немного о цифрах — у 100GE с обычным 1536b пакетами скорость классификации близка к 10Mpps — далеко не все современные фреймворки способны переваривать такой рейт на чем-то, кроме топовых процессоров. Если вас вдруг начнут атаковать и пакет рейт вырастет на порядок — x86 просто не будет способен это переварить, по нескольким причинам:
а) нельзя масштабироваться на соседние NUMA-ноды, то есть сокеты, слишком большие потери даже при bulk queuing пакетов для пересылки между процессором и очередями карт, сюда же записываем проблему с работой DCA, который хорошо вывозит работу с картой на сравнительно небольших объемах трафика,
б) классификация пакетов не может съедать ниже определенного числа тактов на пакет, равного примерно полусотне.
Иными словами, хотите крутой и производительный SDN — распределяйте обработку пакетов по коробкам, а там уже не имеет значения, атом ли это или топовый зеон. В сабжевом устройстве единственная задача управляющей платы — запускать линукс с программирующей сущностью, обычно это сцепленный с API матрицы виртуальный свич.
Помнится, не так давно вы были всей конторой не в состоянии замерить clat у дисков, чтобы подтвердить существующую проблему, какие там тесты производительности полок, не смешите :)
В кластере с Ceph также можно предусмотреть failure prediction, с этим нет никаких проблем. 10G порты не переведут железо по стоимости в класс выше (стоимость дисков одной storage-ноды в разы выше стоимости карточки, встроенной или нет, не говоря об остальном). Акценты расставлены, скорее, не в том порядке — сначала идут открытость платформы и дешевизна масштабирования, обе этих сущности практически закрыты для проприетарных коробков. Есть некоторые нюансы насчет географического разнесения, которые пока что за намного большие деньги решены в проприетарных боксах, ну и пожалуй все.
Не хочу плохо говорить про рекспейс, но у них дохлый стек (тот, на котором они сейчас живут), и дикий eviction/addition rate, о ненужности чего было сказано ранее. Что они в той презентации навернули через xapi и зачем — непонятно. Они стучатся лбом о грабли реактивного подхода по кругу, проблемы неудивительны.
Да, чтобы не повторяться в нюансах — тут все расписано. Сейчас мы выросли еще дальше, так как требуется процессить бОльшие объемы трафика, плюс сделали BGP redistribution.
контроллера, что повышает трудозатраты (разработчиков и инженеров) и
прозрачность кода.
Гм, там вроде нет особенных костылей, если не говорить именно про пику.
> Ну и изначально ориентируемся на легкий framework для baremetal с версией для x86
серверов.
Тем не менее, фоллбекать процессинг на менеджмент энжин, при отсутствии возможности сделать требуемое матрицей, вы будете или вместо этого ограничите возможности стандарта per-матрица?
BTW выше вы с Игорем имеете в виду разные чейнинги.
Не совсем понятно — у коммутаторов обычно софтверный датапэс как класс отсутствует, я даже сходу не могу привести обратный пример. Или все же речь про общий апи?
Ссылка на описание:
lists.openwall.net/netdev/2015/05/28/191
lists.openwall.net/netdev/2015/05/29/94
Правила можно взять отсюда:
devconf.cz/filebrowser/download/374
Флудер можно использовать какой угодно (я использую переделанный нетмап, который вместо udp генерит tcp с чексуммами).
Насыщение очереди /32м флудом после докручиваний наступает в районе 495kpps, если выставить рейт 485, то все ок, если 490 или 493 — флоу контроль начинает дергаться и летят софт локапы. Иными словами, любой фильтрующий сины инстанс на линуксе сейчас можно подвесить достаточно дешевой атакой, достаточной для забивания одной очереди карты. Другое дело, что одинокий трансмиттер легко забанить, а флуд со многих ничем не отличается от обычной «теоретической» атаки на синпрокси, так что проблема вряд ли принадлежит к кругу реальных.
а) нельзя масштабироваться на соседние NUMA-ноды, то есть сокеты, слишком большие потери даже при bulk queuing пакетов для пересылки между процессором и очередями карт, сюда же записываем проблему с работой DCA, который хорошо вывозит работу с картой на сравнительно небольших объемах трафика,
б) классификация пакетов не может съедать ниже определенного числа тактов на пакет, равного примерно полусотне.
Иными словами, хотите крутой и производительный SDN — распределяйте обработку пакетов по коробкам, а там уже не имеет значения, атом ли это или топовый зеон. В сабжевом устройстве единственная задача управляющей платы — запускать линукс с программирующей сущностью, обычно это сцепленный с API матрицы виртуальный свич.
Да, liberados — это кубинский форк, стало быть?