Кстати, почему-то Microsoft не пугает использовать FPGA и ставить их в 1632 сервера)
Если очень надо, и без FPGA никак, а разработка занимает в 10 раз больше времени, то может тогда просто нанять 10 FPGA разработчиков? ;) Если это экономически невыгодно, то тогда просто не беритесь за эту задачу :)
от FPGA требовалось парсить пакет (MAC/IP/UDP) на 10G, находить там RTP-данные, упаковывать в специальный бинарный формат, а затем упаковывать в UDP-пакеты и отправлять на 1G. При уже готовых 10G и 1G MAC-ядрах и готовой системе парсинга пакета от идеи до демонстрации на реальном трафике у оператора прошло две недели. Под FPGA пиcал один человек.
Если и это медленно, то наверно мне надо начать медленее писать код)
В качестве IDE для написания кода под FPGA (Verilog), я использую vim. Особых проблем с этим не имею)
По поводу медленнее расскажу пример из конкретной жизни:
балансировка 100G -> 10x10G и 1000 правил фильтрации 100G linerate при уже имеющихся MAC-ядрах 100G и 10G у двух FPGA-разработчиков заняло месяц.
Я в статье рассказал про карточки от различных вендоров, их ТТХ, а так же общий обзор: что туда запихивают из железа.
Кто и как их использует — это сумма того, что я видел в интернете, какие запросы на разработку к нам приходят, а так же общение с коллегами из других фирм. А использует ли кто-то [в мире] для этих задач Microblaze или нет — я не знаю.
Когда мы решаем эти (или похожие) задачи на своих железках (они с FPGA, но без PCIe) — мы не используем NIOS/Microblaze, потому что когда ты хочешь фильтровать 5-tuple или LPM на linerate 10G/40G/100G, то, боюсь, производительности софтового проца не хватит. Возможно для какого-то более глубокого анализа и можно его применить, не знаю.
Попробую защитить разработку под FPGA (применительно к Альтере, т.к. я пишу под неё).
1. Да, это норма. Бывает и побольше. Когда мы делали анализатор/балансировщик 100G, то полная сборка с нуля занимала 5-6 часов. На самом деле это не так страшно, т.к. сборка производится очень редко (допустим, в конце недельного спринта, когда делается релиз прошивки), и, разумеется, делается ночью. Весь код предварительно прогоняется в симуляторе, где очень быстрая сборка (минута), отлаживается там же, и затем просто собирается квартусом. Очень редко что-то приходится смотреть сигналтапом (раз в квартал, наверно).
2. Вы про BSP для девкитов?
3. Это такое же программирование, как и любое другое: с предсказуемым временем на разработку. Есть небольшой свод правил, которым надо следовать и всё будет хорошо. Да, сортировку под FPGA надо писать с нуля день, а в C просто вызвать qsort, но таковы реалии. Кстати, попробуйте с нуля, никуда не подглядывая, написать сортировку на ассемблере, думаю тоже будет «тяжело и чертовски долго».
4. Да, есть такой минус.
5. За четыре года работы я видел только три бага квартуса. Не знаю, это много или нет. Не забываете, что пользователей gcc в десятки тысяч раз больше, чем пользователей квартуса. Ну, а проблемы с кириллицей и documents and settings мне не знакомы — я на linux'e сижу)
6. Наличие быдлокода зависит очень о того, кто пишет) Да, иногда не самые оптимильные по количеству строк решения вылезают из-за ограничения языка, который используется. Но есть у вас в проекте быдлокод, это значит, что тот код делает ревью, делает это неправильно, или сам пишет быдлокод (как и в любом другом языке). Не очень понял про независимость модулей и про сумасшедшую гонку чипов.
7. Да, дорогие, потому что разработка под FPGA это «тяжело и чертовски долго» :).
8. Да, такое встречается. Зависит от специфики проектов/IP-ядер.
У Альтеры есть пример парсера OPRA FAST (для HFT) на OpenCL, который:
The kernel parses incoming compressed OPRA Fast data from a UDP offload engine, and returns a subset of fields over Ethernet with the UDP offload engine. The UDP offload engines are represented as I/O channels to the kernel.
UDP оffload engine — это ядро, ссылку на который я давал ранее.
Поэтому высокоуровне программировать FPGA можно. Насколько это будет эффективно в конкретной задаче — это другой вопрос.
Многих пугает и останавливает большой ценник на такие платы с FPGA: от 4 до 15 тысяч долларов (и более).
Кому реально надо — те покупают готовые решения с фильтрацие за очень большие деньги, либо покупают девкиты и нанимают разработчиков для написания аппаратных фильтров/туннелей и пр.
Если платы будут по 300$, то это наверно будет совершенно другой разговор, да и цена формируется же рынком)
С одной стороны, это действительно просто железо, как, скажем процессор от Интела. Программы для него — это уже проблема разработчика.
Действительно для FPGA мало открытых либ, т.к. эта сфера очень специфичная. Кому надо либо покупают готовые IP-ядра (см. выше, где был пример про TCP/UDP ядра), либо пишут сами (заказывают у контор, которые пишут IP-ядра).
Для зашивки/разрботки программ на FPGA используются SDK от вендоров, разработчики плат предоставляет референсные дизайны/bsp.
Программу на scapy и скомпилировать в код в FPGA не сможете.
Без проблем управляемая до уровня XGMII, на более низком уже сложнее/невозможно.
А бесплатно: мы никаких сертификатов не выдаем, и никак не связаны с вендорами (официально, как, например, Политех).
Они позиционируется для студентов старших курсов, а не для серьезных дядечек)
Система мониторинга была сдана заказчику в марте, поэтому в ближайшее время каких-то улучшений не планируется (насколько мне известно).
Признаюсь, в январе-феврале были горячие деньки, когда после выкатывания новой фишечки, мы заходили в top с боязнью. В такие моменты у нас в комнате и произносились магические слова DPDK, ZeroCopy и пр. Но до использования этого у нас руки не дошли:
Во-первых, никто из нас с этим не работал ранее: большинство разработок у нас это embedded.
Во-вторых, был небольшой скепсис, что это нам поможет: мы явно видели, что потребление проца возрастает после включения определенной фишки в обработке, а нагрузка на сетевую карту была такой же.
В итоге, помимо алгоритмических оптимизаций в софте, мы сделали два архитектурных изменения:
Мы изначально понимали, что один htpdec не справится со всей нагрузкой, и его надо параллелить. Сначала мы делали балансировку на проце — был процесс htpmap, который принимал весь поток и распределял между несколькими htpdec'ами. Получалось, что по факту этот процесс копирует данные из одного места в другие (из одного сокета в другие) и ел много CPU. Мы отказались от этого и решили сначала запустить четыре htpdec'a, которые будут слушать udp-порты, причем, htpdec0 слушает выход с линков 1 и 2, а htpdec1 — с 3 и 4 и так далее (так были настроены порты в MX'e). Так как линков было семь, равномерно, конечно, данные не распределялись (htpdec3 достался только линк 7). Так же, линки не были нагружены одинаково (да и иногда линки падали — и трафик перераспределялся на другие линки), и мы видели, что два процесса едят по 90%, а другие два по 45%. Нас это беспокоило, и мы запилили балансировку на уровне FPGA: считаем хэш от ip_src и отправляем на нужный udp-порт. Тем самым у нас все четыре процесса получают одинаковую нагрузку (вне зависимости от нагрузки и распределения на линках).
Изначально пакеты между MX и сервером были размером ~1500 байт, при нагрузке 3 Гбит/c это около 250K пакетов в секунду. Мы заставили MX отправлять нужные нам кусочки в jumbo фреймах (~8000 байт), а это получается около 47K пакетов в секунду. Как понимаете, это не совсем та нагрузка при которой надо расчехлять DPDK. К сожалению, у меня сейчас нет возможности посмотреть сколько приходит прерываний в секунду и сколько ест ksoftirq. Возможно, у Павла есть такая возможность)
Читая статьи о реверс-инжиниринге Майкрософтских программ иногда кажется, что не видя исходный код такое раскопать невозможно...(а это говорит о мастерстве автора :) ).
Или может намного проще понять в чем проблема НЕ имея исходный код, чем бегать по сотням классов/функций в IDE и читать код?
По результатам этой работы получили ли вы фидбэк от волонтеров и добавились ли какие-то улучшения/фишечки в продукты ABBYY?
К примеру, стало понятно, что вот это сделано неудобно при редактировании больших объемов и в новой версии было (или планируется) улучшить?
Спасибо за статью!
Совершенно случайно не знаете, используют ли какие-то сетевые железки именно этот алгоритм для подсчета количества соединений?
И если да, то какие?
Как я и писал выше, в продакшене мы используем SystemVerilog.
Пример с Verilog'ом я привёл, т.к. много разработчиков, которые сидят на Verilog'e в силу исторических причин (синтезатор, старые проекты и так далее).
Как считаете, стоит переходить с SystemVerilog на Bluespec? Какие приемущества получается?
Коллеги,
служба поддержки сказала, что этот топик мониторится, и возможно, наше мнение на что-то повлияет.
Я приведу контр-пример, что «FPGA для гиков»:
вчера выложил статью, она написана FPGA разработчиком для тех, кому интересна разработка под FPGA, но статья не попала к своей целевой аудитории, т.к. хаб FPGA переехал на Geektimes.
Статью на Geektimes я не могу (и не хочу) выкладывать, т.к.:
в ней есть код
статья не для гиков, а для разработчиков, моих коллег
гаджет я в ней не делаю и тем более не разбираю
Получается, что, написав статью, я не достиг цели, т.к. моя аудитория теперь на другом ресурсе, а на хабы типа Python мои коллеги могут быть не подписаны.
Мотивирует ли меня писать что-то дальше про FPGA (а я этим занимаюсь не по вечерам, моргая светодиодиком, а каждый день на работе)?
Да, скорее всего, нас на ресурсе намного меньше чем сайтописателей, либо линукс-программистов и специалистов по безопасности.
Но я не понимаю почему код под FPGA или микроконтроллеры должен теперь быть на Geektimes.
Если FPGA обратно не перенесут, то предлагаю организовать хаб:
HDL (hardware description language) [это класс языков, на котором описываются схемы. Сюда входят VHDL и Verilog/SystemVerilog].
На мой взгляд, преимущество раскрывается во второй части статьи, где из шаблона автогенерится модуль csr_map, где и используются питоновские типы данных.
Да, шаблон пишется руками, то при наличии 50-100 регистров и необходимости создания такого модуля вопрос в целесообразности отпадает)
Как я и говорил, пример с мультиплексором детский и конкретно его можно было сделать ручками. А вот что-то типа такого (генерилка на питоне и получившийся модуль на верилоге) уже ручками писать не захочется.
Конкретно в продакшене FPGA мы питон не используем для генерации Verilog-кода, т.к.:
используем SystemVerilog (проблем с массивами в портах нет)
красивого разбиения на IP-ядра у нас нет и система CSR проще, чем та, которую я показывал в статье
В реальной жизни мы автогенерилку, написанную на питоне, используем для генерации Сишных функций аналогичные tse_update_mac_addr из описания регистров. Это реально снимает часть рутины, когда я выдаю разработчикам какую-то новую фичу с 20-30 регистрами.
Цель статьи:
показать, что есть связка Python + Jinja, благодаря которой можно, написав шаблон, генерить различный текст, в том числе и код на Verilog'e.
Если у кого-то встанет такая задача, и он вспомнит про мою статью — буду рад, значит не зря написал)
Если очень надо, и без FPGA никак, а разработка занимает в 10 раз больше времени, то может тогда просто нанять 10 FPGA разработчиков? ;) Если это экономически невыгодно, то тогда просто не беритесь за эту задачу :)
система мониторинга RTP-потоков, которую описывал мой коллега в habrahabr.ru/company/metrotek/blog/266561
от FPGA требовалось парсить пакет (MAC/IP/UDP) на 10G, находить там RTP-данные, упаковывать в специальный бинарный формат, а затем упаковывать в UDP-пакеты и отправлять на 1G. При уже готовых 10G и 1G MAC-ядрах и готовой системе парсинга пакета от идеи до демонстрации на реальном трафике у оператора прошло две недели. Под FPGA пиcал один человек.
Если и это медленно, то наверно мне надо начать медленее писать код)
По поводу медленнее расскажу пример из конкретной жизни:
балансировка 100G -> 10x10G и 1000 правил фильтрации 100G linerate при уже имеющихся MAC-ядрах 100G и 10G у двух FPGA-разработчиков заняло месяц.
Если это медленно и пугает, то я даже не знаю…
Кто и как их использует — это сумма того, что я видел в интернете, какие запросы на разработку к нам приходят, а так же общение с коллегами из других фирм. А использует ли кто-то [в мире] для этих задач Microblaze или нет — я не знаю.
Когда мы решаем эти (или похожие) задачи на своих железках (они с FPGA, но без PCIe) — мы не используем NIOS/Microblaze, потому что когда ты хочешь фильтровать 5-tuple или LPM на linerate 10G/40G/100G, то, боюсь, производительности софтового проца не хватит. Возможно для какого-то более глубокого анализа и можно его применить, не знаю.
1. Да, это норма. Бывает и побольше. Когда мы делали анализатор/балансировщик 100G, то полная сборка с нуля занимала 5-6 часов. На самом деле это не так страшно, т.к. сборка производится очень редко (допустим, в конце недельного спринта, когда делается релиз прошивки), и, разумеется, делается ночью. Весь код предварительно прогоняется в симуляторе, где очень быстрая сборка (минута), отлаживается там же, и затем просто собирается квартусом. Очень редко что-то приходится смотреть сигналтапом (раз в квартал, наверно).
2. Вы про BSP для девкитов?
3. Это такое же программирование, как и любое другое: с предсказуемым временем на разработку. Есть небольшой свод правил, которым надо следовать и всё будет хорошо. Да, сортировку под FPGA надо писать с нуля день, а в C просто вызвать qsort, но таковы реалии. Кстати, попробуйте с нуля, никуда не подглядывая, написать сортировку на ассемблере, думаю тоже будет «тяжело и чертовски долго».
4. Да, есть такой минус.
5. За четыре года работы я видел только три бага квартуса. Не знаю, это много или нет. Не забываете, что пользователей gcc в десятки тысяч раз больше, чем пользователей квартуса. Ну, а проблемы с кириллицей и documents and settings мне не знакомы — я на linux'e сижу)
6. Наличие быдлокода зависит очень о того, кто пишет) Да, иногда не самые оптимильные по количеству строк решения вылезают из-за ограничения языка, который используется. Но есть у вас в проекте быдлокод, это значит, что тот код делает ревью, делает это неправильно, или сам пишет быдлокод (как и в любом другом языке). Не очень понял про независимость модулей и про сумасшедшую гонку чипов.
7. Да, дорогие, потому что разработка под FPGA это «тяжело и чертовски долго» :).
8. Да, такое встречается. Зависит от специфики проектов/IP-ядер.
У Альтеры есть пример парсера OPRA FAST (для HFT) на OpenCL, который:
www.altera.com/support/support-resources/design-examples/design-software/opencl/opra-fast.html
UDP оffload engine — это ядро, ссылку на который я давал ранее.
Поэтому высокоуровне программировать FPGA можно. Насколько это будет эффективно в конкретной задаче — это другой вопрос.
Многих пугает и останавливает большой ценник на такие платы с FPGA: от 4 до 15 тысяч долларов (и более).
Кому реально надо — те покупают готовые решения с фильтрацие за очень большие деньги, либо покупают девкиты и нанимают разработчиков для написания аппаратных фильтров/туннелей и пр.
Если платы будут по 300$, то это наверно будет совершенно другой разговор, да и цена формируется же рынком)
Действительно для FPGA мало открытых либ, т.к. эта сфера очень специфичная. Кому надо либо покупают готовые IP-ядра (см. выше, где был пример про TCP/UDP ядра), либо пишут сами (заказывают у контор, которые пишут IP-ядра).
Для зашивки/разрботки программ на FPGA используются SDK от вендоров, разработчики плат предоставляет референсные дизайны/bsp.
Программу на scapy и скомпилировать в код в FPGA не сможете.
Без проблем управляемая до уровня XGMII, на более низком уже сложнее/невозможно.
Они позиционируется для студентов старших курсов, а не для серьезных дядечек)
Сейчас выпускается вторая ревизия — в синей раскраске, и SFP порты в два ряда.
Признаюсь, в январе-феврале были горячие деньки, когда после выкатывания новой фишечки, мы заходили в top с боязнью. В такие моменты у нас в комнате и произносились магические слова DPDK, ZeroCopy и пр. Но до использования этого у нас руки не дошли:
Во-первых, никто из нас с этим не работал ранее: большинство разработок у нас это embedded.
Во-вторых, был небольшой скепсис, что это нам поможет: мы явно видели, что потребление проца возрастает после включения определенной фишки в обработке, а нагрузка на сетевую карту была такой же.
В итоге, помимо алгоритмических оптимизаций в софте, мы сделали два архитектурных изменения:
Мы изначально понимали, что один htpdec не справится со всей нагрузкой, и его надо параллелить. Сначала мы делали балансировку на проце — был процесс htpmap, который принимал весь поток и распределял между несколькими htpdec'ами. Получалось, что по факту этот процесс копирует данные из одного места в другие (из одного сокета в другие) и ел много CPU. Мы отказались от этого и решили сначала запустить четыре htpdec'a, которые будут слушать udp-порты, причем, htpdec0 слушает выход с линков 1 и 2, а htpdec1 — с 3 и 4 и так далее (так были настроены порты в MX'e). Так как линков было семь, равномерно, конечно, данные не распределялись (htpdec3 достался только линк 7). Так же, линки не были нагружены одинаково (да и иногда линки падали — и трафик перераспределялся на другие линки), и мы видели, что два процесса едят по 90%, а другие два по 45%. Нас это беспокоило, и мы запилили балансировку на уровне FPGA: считаем хэш от ip_src и отправляем на нужный udp-порт. Тем самым у нас все четыре процесса получают одинаковую нагрузку (вне зависимости от нагрузки и распределения на линках).
Изначально пакеты между MX и сервером были размером ~1500 байт, при нагрузке 3 Гбит/c это около 250K пакетов в секунду. Мы заставили MX отправлять нужные нам кусочки в jumbo фреймах (~8000 байт), а это получается около 47K пакетов в секунду. Как понимаете, это не совсем та нагрузка при которой надо расчехлять DPDK. К сожалению, у меня сейчас нет возможности посмотреть сколько приходит прерываний в секунду и сколько ест ksoftirq. Возможно, у Павла есть такая возможность)
Или может намного проще понять в чем проблема НЕ имея исходный код, чем бегать по сотням классов/функций в IDE и читать код?
По результатам этой работы получили ли вы фидбэк от волонтеров и добавились ли какие-то улучшения/фишечки в продукты ABBYY?
К примеру, стало понятно, что вот это сделано неудобно при редактировании больших объемов и в новой версии было (или планируется) улучшить?
Совершенно случайно не знаете, используют ли какие-то сетевые железки именно этот алгоритм для подсчета количества соединений?
И если да, то какие?
Пример с Verilog'ом я привёл, т.к. много разработчиков, которые сидят на Verilog'e в силу исторических причин (синтезатор, старые проекты и так далее).
Как считаете, стоит переходить с SystemVerilog на Bluespec? Какие приемущества получается?
служба поддержки сказала, что этот топик мониторится, и возможно, наше мнение на что-то повлияет.
Я приведу контр-пример, что «FPGA для гиков»:
вчера выложил статью, она написана FPGA разработчиком для тех, кому интересна разработка под FPGA, но статья не попала к своей целевой аудитории, т.к. хаб FPGA переехал на Geektimes.
Статью на Geektimes я не могу (и не хочу) выкладывать, т.к.:
Получается, что, написав статью, я не достиг цели, т.к. моя аудитория теперь на другом ресурсе, а на хабы типа Python мои коллеги могут быть не подписаны.
Мотивирует ли меня писать что-то дальше про FPGA (а я этим занимаюсь не по вечерам, моргая светодиодиком, а каждый день на работе)?
Да, скорее всего, нас на ресурсе намного меньше чем сайтописателей, либо линукс-программистов и специалистов по безопасности.
Но я не понимаю почему код под FPGA или микроконтроллеры должен теперь быть на Geektimes.
Если FPGA обратно не перенесут, то предлагаю организовать хаб:
Да, шаблон пишется руками, то при наличии 50-100 регистров и необходимости создания такого модуля вопрос в целесообразности отпадает)
Как я и говорил, пример с мультиплексором детский и конкретно его можно было сделать ручками. А вот что-то типа такого (генерилка на питоне и получившийся модуль на верилоге) уже ручками писать не захочется.
Конкретно в продакшене FPGA мы питон не используем для генерации Verilog-кода, т.к.:
В реальной жизни мы автогенерилку, написанную на питоне, используем для генерации Сишных функций аналогичные tse_update_mac_addr из описания регистров. Это реально снимает часть рутины, когда я выдаю разработчикам какую-то новую фичу с 20-30 регистрами.
Цель статьи:
показать, что есть связка Python + Jinja, благодаря которой можно, написав шаблон, генерить различный текст, в том числе и код на Verilog'e.
Если у кого-то встанет такая задача, и он вспомнит про мою статью — буду рад, значит не зря написал)
Конечно, пример с мультиплексором был чисто для введения, и не обязательно делать автогенерилку в таком случае.