Ethernet + PCIe + FPGA = LOVE

    image

    Доступ по Ethernet невозможен без сетевых карточек (NIC). На небольших скоростях (до 1G) NIC встраивают в материнки, а на больших (10G/40G) NIC размещается на отдельной PCIe плате. Основным ядром такой платы является интегральный чип (ASIC), который занимается приемом/отправкой пакетов на самом низком уровне. Для большинства задач возможностей этого чипа хватит с лихвой.

    Что делать, если возможностей сетевой карточки не хватает? Либо задача требует максимально близкого доступа к низкому уровню? Тогда на сцену выходят платы с перепрограммируемой логикой — ПЛИС (FPGA).

    Какие задачи на них решают, что размещают, а так же самых интересных представителей вы увидите под катом!

    Осторожно, будут картинки!

    План:



    Применения FPGA-плат


    DPI, фильтрация и фаервол


    image

    Сервер с такой платой может встать в «разрыв» и мониторить все пакеты, проходящие через него. Интеллектуальный DPI реализуется на базе процессора, а переброска пакетов и простая фильтрация (например, много правил 5-tuple) реализуется на базе ПЛИС.

    Как это можно сделать:

    • Потоки, которым мы доверяем, либо решение по ним уже находится в таблице по FPGA, проходят насквозь чипа с небольшой задержкой, остальные копируются на CPU и там делается обработка.
    • FPGA может снимать часть нагрузки с CPU и искать подозрительные сигнатуры у себя, например, по алгоритму Блума. У этого алгоритма есть вероятность ложно-положительного срабатывания, поэтому если в пакете нашлась строчка, на которую среагировал Блум, то такой пакет копируется на CPU для дополнительного анализа.
    • На процессоре обрабатывается только тот трафик, который интересен — FPGA отбирает по заданным критериям пакеты (например, HTTP-запросы или SIP трафик) и копирует их на CPU, всё остальное (торренты, видео и пр.) проходят через FPGA без значительной задержки.

    Все эти три варианта могут быть скомбинированы в различных вариациях. Так же FPGA может делать какую-нибудь еще грязную работу, например, выступать в качестве шейпера/полисера, либо собирать статистику по потокам.

    На иллюстрации выше зеленые пакеты обрабатываются на CPU, бордовые и желтые прошли через фильтры в FPGA, а розовые были дропнуты (тоже в FPGA).

    Анализ и захват трафика


    image

    Иногда такие платы используют для захвата трафика и дальнейшей постобработке на CPU (запись в pcap, анализ задержек и пр.). В таком случае в линки вставляется сплиттер (или трафик забирается с миррор порта). Получается неинтрузивное подключение, аналогичное тому, как мы делали в проекте мониторинга RTP-потоков.

    Здесь от ПЛИС требуется:

    • Фильтрация по полям (типа 5-tuple): для отбора только того трафика, который интересен.
    • Синхронизация по PTP, для аппаратного timestamping пакетов: защелкивается время, когда пришел пакет, и эта метка размещается в конец пакета. Затем на CPU можно посчитать, например, время отклика на запрос.
    • Слайсинг — отрезание только необходимого куска данных (чаще всего это первые N байт от пакета — для того, чтобы копировать только заголовки, т.к. очень часто данные не очень интересны,).
    • Буферизация пакетов:
      • если CPU не успевает записывать в случае каких-то берстов, то можно это сгладить, если разместить пакеты во внешней памяти на пару гигабайт
      • если мы хотим гарантировать запись пакетов в течении небольшого времени (например, после срабатывания триггера) — чаще всего применимо для больших скоростей (40G/100G).
    • Раскидывания пакетов по очередям и ядрам CPU.

    Имея доступ к самому низкому уровню (ну, почти), можно поддержать любой протокол или туннелирование, а не ждать, пока Intel это сделает в своих карточках.

    На приведенной иллюстрации FPGA принимает все пакеты после ответвления трафика, но на CPU копируются только те, которые нас интересуют (розовенькие).

    Сетевая карточка


    Карточки с ПЛИС можно использовать в качестве обычного NIC, но смысла в этом не много:

    • На сегодняшний момент на всех скоростях Ethernet (до 100G включительно) есть сетевые карточки на базе ASIC'ов. По цене они будут дешевле, чем решения на FPGA.
    • Если писать карточку самому, то для более менее серьезной производительности необходимо в такой карточке накрутить огромное количество плюшек (RSS, LSO, LRO).

    Смысл появляется только тогда, когда необходимо обеспечить уникальную фишку, которой никогда не будет в чипе от Intel'a. Например, аппаратного шифрования по ГОСТу или Кузнечику.

    Cетевой ускоритель


    Снижение нагрузки с CPU


    Когда появляются большие скорости, процессор не успевает всё делать: хочется часть задач с него снять. Например, что происходит когда вы копируете какой-то большой объем данных по сети?

    Процессор должен:

    • взять какой-то кусок данных
    • засунуть в TCP, разбить на несколько пакетов, согласно MTU
    • подставить заголовок (MAC/IP-адреса)
    • рассчитать чексуммы IP и TCP (хотя большинство NIC это уже берут на себя)
    • передать дескриптор в NIC

    Так же надо:

    • следить за ответами
    • перепосылать пакеты, если пакет потерялся
    • снижать/повышать tcp-window и так далее


    TCP-стек может быть реализован на FPGA: CPU достаточно предоставить указатель на сырые данные и IP+порт получателя, а всей низкоуровневой работой (установкой соединения, перепосылками, и пр.) займется железка.

    Есть готовые IP-ядра, которые всё это делают: например, реализации TCP и UDP стеков от компании PLDA.

    Они имеют стандартные интерфейсы (Avalon или AXI), что позволяет их легко соединять с другими IP-ядрами.
    image

    Ускорение ответа


    Есть класс задач, где деньги приносят не процессоры, а скорость реакции. Конечно, я о High Frequency Trading. О роли FPGA в HFT можно прочитать в этой статье.

    На сайте PLDA приведено видео и пример архитектуры, как это делается. Использование аппаратных TCP и UDP ядер позволяет уменьшать лэтенси на покупки/продажи.



    image

    Скрытый текст
    Прошу прощения за красные подчеркивания — картинка взята с сайта PLDA, и у них так в оригинале...

    Есть специальные IP-ядра, которые декодируют данные с рынков и готовы к сопряжению с аппаратными TCP и UDP стеками.

    Разумеется, использование стандартных ядер или подходов преимущества перед конкурентами не даст: разрабатываются эксклюзивные решения, т.к. «хотят еще меньшую задержку».

    Оборудование для измерений


    Эмуляторы сетей


    Очень часто происходит, что надо проверить инженерное решение в лаборатории, т.к. в боевых условиях это может быть очень дорого.
    Недавно была статья от КРОК, про оптимизацию трафика в условиях Севера и большого RTT. Для проверки того, какое будет качество услуг в реальных условиях, сначала надо создать эти условия у себя в лаборатории. Для этого можно применить и обычную линуксовую машину, но есть специальные железки, которые занимаются эмуляцией сети.

    Чаще всего необходимо уметь задавать такие параметры как задержка/джиттер, потери (ошибки) пакетов. Без аппаратной поддержки (читай, ПЛИС) здесь не обойтись, но так же нужен и «умный» процессор, для эмуляции различных протоколов (сессий пользователей). Для того, что бы не разрабатывать железо с нуля можно взять сервер и вставить PCIe карточку с FPGA.

    Ускорение вычислений


    Такие карточки так же можно использовать для ускорения каких-то вычислений или моделирования, например, для биологии или химии. О примере такого моделирования рассказывала Algeronflowers в этой статье. В таком случае порты Ethernet могут и не понадобиться, а с другой стороны могут быть полезны, если захочется сделать ферму из плат: входные или выходные данные для расчета передавать через Ethernet.

    OpenCL


    image

    Иногда нет необходимости выжимать из железа все соки: очень часто важен time-to-market. Многие разработчики отказываются от использования FPGA, т.к. их пугает низкоуровневая оптимизация до тактов (плюс необходимо знать новый язык(и) и инструмент). Хотелось бы писать код на «выcоком» уровне, а компилятор уже всё разложит по триггерам/блокам памяти. Один из таких вариантов является OpenCL. Altera и Xilinx поддерживают.

    OpenCL на FPGA это тема отдельной статьи (и не одной). Рекомендую для ознакомления презентацию от Альтеры про обзор технологии и маршрут разработки под FPGA.

    HighLoad


    В интернете можно найти много новостей, о том, что гиганты присматриваются к ПЛИС для обработки больших данных в датацентрах.

    Так, была заметка о том, что Microsoft для ускорения поисковой системы Bing использует FPGA. Технические подробности можно найти в публикации A Reconfigurable Fabric for Accelerating Large-Scale Datacenter Services.

    К сожалению, хорошей технической статьи на русском языке об этом нет, хотя тема очень интересная. Может olgakuznet_ms или её коллеги исправят этот недостаток?

    Надеюсь, что выпуск чипов CPU + FPGA подстегнет разработчиков высоконагруженных систем переносить часть вычислений на FPGA. Да, разработка под FPGA «сложнее» чем под CPU, но на конкретных задачах может давать замечательный результат.

    Разработка/отладка IP-ядер и софта


    Такие платы еще могут использовать ASIC/FPGA разработчики для верификации своих IP-ядер, которые потом могут запускаться на совершенно других железках.

    Очень часто бывает, что софт пишется одновременно с тем, как разрабатывается/производится железка, и отлаживать софт где-то уже надо. В данном контексте софт это как прошивка FPGA + различные драйвера и юзерспейсные программы. В проекте 100G анализатора и балансировщика возникли задачи, которые мы никогда не решали:

    • настройка FPGA (CSR: контрольно-статусные регистры) должна происходить через PCIe
    • для linux'a FPGA с кучей интерфейсов должна выглядеть как сетевая карточка: необходимо написать драйвер(ы), и переброску пакетов c/на хост

    Конечно, параллельно были и другие задачи (типа генерации/фильтрации 100G трафика), но они спокойно решались в симуляторе, а вот эти две задачи в симуляторе не особо погоняешь. Что мы сделали? Оказалось, что у нас есть девборда от Альтеры. Не смотря на то, что там совершенно другой чип, другой PCIe и пр. мы на ней отладили связку FPGA + драйвера, а когда отдел производства передал нам плату для b100, то после поднятия железа вся эта связка без проблем заработала.

    Общая схема


    image
    Перед обзором карточек, рассмотрим общую схему таких PCIe карточек.

    Ethernet


    Платы оснащаются стандартными Ethernet-разъемами:
    • SFP — 1G
    • SFP+ — 10G
    • QSFP — 40G
    • CFP/CFP2/CFP4 — 100G

    Чаще всего встречаются такие комбинации:
    • 4 x SFP/SFP+
    • 2 x QSFP
    • 1 x CFP

    О том, что происходит на низком уровне и как происходит подключение к 10G к интегральным схемам можно прочитать, например, тут.

    PCIe


    Стандартный разъем, который можно воткнуть в компьютер с обычной материнкой. На текущий момент, топовые FPGA поддерживают аппаратные IP-ядра Gen3 x8, но этой пропускной способности (~63 Gbps) хватает не для всех задач. На некоторых платах стаят PCIe свитч, который 2 канала Gen3 x8 объединяет в один Gen3 x16.

    На будущих чипах Altera и Xilinx заявляют о аппаратной поддержке Gen3 x16, и даже о Gen4.

    Коннекторы


    image

    Иногда размещают разъем(ы) для подключения плат расширения, однако единого стандарта де-факто нет (типа USB). Чаще всего встречаются VITA ( FMC ) и HSMC.

    Avago MiniPod


    image

    У вышеобозначенных коннекторов есть небольшой недостаток — они металлические и на высоких частотах/длинных расстояниях затухание может быть значительным.

    В ответ на эту проблему Avago разработало Avago Minipod: оптические приемо-передатчики. Они готовы передавать 12 лейнов по 10-12.5GBd. По размерам коннектор сравним с монеткой. С помощью такого разъема можно соединять не только рядом стоящие платы, но и делать связь в суперкомпьютерах или в стойках между серверами.



    Когда наши коллеги показывали демку MiniPod'a на вот такой борде, то рассказывали, что никаких дополнительных IP-ядер или Verilog-кода не надо вставлять — эти модули просто подключаются в входам/выходам трансиверам FPGA, и всё работает.

    Внешняя память


    Памяти в ПЛИС не так много — в топовых чипах их 50-100 Mbit. Для обработки больших данных к чипу подключают внешнюю память.
    Выделяют два типа памяти:


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

    У Альтеры есть External Memory Interface Handbook, который как не сложно догадаться, посвящен внешней памяти. Заинтересовавшийся читатель в главе Selecting Your Memory найдет таблицы сравнения различных типов памяти и советы по выбору. Сам гайд доступен тут (осторожно, файл большой).

    Если смотреть на применение памяти в сетях связи, то советы примерно такие:

    • DRAM используют для создания больших буферов (под пакеты)
    • SRAM:
      • таблицы/структуры принятий решения куда отправлять пакет
      • структуры для управления очередями
      • подсчет пакетной статистики (RMON и пр.)
    • возможен гибридный подход — DRAM используют для хранения полезной нагрузки пакета, а в SRAM размещают только заголовок

    Если открыть презентацию Anatomy of Internet Routers от Cisco, то можно увидеть, что в качестве DRAM они в некоторых роутерах используют именно RLDRAM.

    HMC


    HMC (Hybrid Memory Cube) — это новый тип ОЗУ памяти, которая может в некоторых приложениях вытеснить DDR/QDR память: обещают значительное ускорение пропускной способности и меньшее энергопотребление. На хабре можно найти новости: раз и два. В комментариях к ним можно найти опасения, что до этого еще далеко и так далее.

    Заверяю вас, что всё не так плохо. Так, полгода(!) назад, наши коллеги из EBV показывали работающую демоборду из четырех Stratix V (по бокам) и HMC (в центре).

    image

    Ожидается, что коммерческие образцы (для масспродакта) будут доступны в 2015 году.

    Обзор PCIe карточек


    Обзор, наверно, это слишком громкое слово — я попытаюсь показать самых интересных представителей от разных компаний. Никаких таблиц сравнения или анпакинга не будет. На самом деле большого разнообразия между платами не будет, они все вписываются в «шаблон», который был описан ранее. Уверен, что можно найти еще около пяти-семи фирм, который выпускают такие платы, а самих плат еще с десяток.

    NetFPGA 10G


    image

    Скрытый текст
    FPGA:

    • Xilinx Virtex-5 TX240T
    • 240K logic cells
    • 11,664 Kbit block RAM

    10-Gigabit Ethernet networking ports
    • 4 SFP+ connectors

    Quad Data Rate Static Random Access Memory (QDRII SRAM)
    • 300MHz Quad data rate (1.2 Giga transactions every second), synchronous with the logic
    • Three parallel banks of 72 MBit QDRII+ memories
    • Total capacity: 27 MBytes
    • Cypress: CY7C1515KV18

    Reduced Latency Random Access Memory (RLDRAM II)
    • Four x36 RLDRAMII on-board device
    • 400MHz clock (800MT/s)
    • 115.2 Gbps peak memory throughput
    • Total Capacity: 288MByte
    • Micron: MT49H16M36HT-25


    Это не самая топовая карточка, но про неё я не рассказать не мог:

    • платы NetFPGA позиционируются как «открытые платформы для исследований»: они используются по всему миру (в более чем 150 заведениях). Студенты/научные сотрудники могут делать на них различные лабораторные работы/проекты.
    • проект позиционируется как opensource: на гитхабе есть одноименная организация. На гитхабе в приватном репозитории лежат различные референсные дизайны (сетевая карточка, свитч, роутер и пр.), которые написаны на Verilog'e и распространяется под LGPL. Они станут доступны после простой регистрации.

    Advanced IO V5031



    image

    Скрытый текст
    • Altera Stratix V
    • Quad 10 Gigabit Ethernet SFP+ optical ports
    • 2 banks of 1GB to 8GB 72-bit 1066MHz DDR3 SDRAM
    • 4 banks of 36Mbit to 144Mbit 18-bit 350MHz QDRII+ SRAM
    • x8 PCI Express Gen 3
    • PPS Interface for time synchronization with microsecond resolution


    У этой платы есть брат-близнец: captureXG 1000, но он уже позиционируется как карточка для записи потоков данных:

    Скрытый текст
    • Time Synchronization: IRIG-A, B and G time synchronization via a front panel SMA connector
    • Filters: 128 programmable 5-tuple filters ( IPv4, TCP, UDP, ICMP, ARP )
    • Packet Capture: PCAP Next Generation format or raw data format


    Фактически к карточке, которая была показана выше, написали прошивку для FPGA, а так же драйвера. И это уже фактически получается другой продукт, который готов к работе «из коробки». Интересно какая разница по деньгам между этими двумя продуктами.

    Napatech NT40E3-4-PTP



    image

    Еще одна карточка для записи и анализа трафика:

    Скрытый текст
    • FPGA: Xilinx Virtex-7
    • Quad 10 Gigabit Ethernet SFP+ optical ports
    • 4 GB DDR3
    • PCIe x8 Gen 3

    Увы, больше технических подробностей из маркетинговой брошюры выжать не удалось.



    В таком корпусе она выглядит очень симпатично. Принципиально по железу эта карточка не особо отличается от других, но Napatech её рассматривает как законченный продукт и навернул туда кучу фич, которые реализуются на FPGA:

    Скрытый текст
    • Hardware Time Stamp
    • Full line-rate packet capture
    • Frame buffering
    • Frame and protocol information
    • Time Stamp Injection
    • Buffer size configuration
    • Onboard IEEE 1588-2008 (PTP v2) support
    • Inter-Frame Gap Control
    • Frame Classification
    • HW Time Synchronization
    • Extended RMON1 port statistics
    • Advanced Statistics
    • Synchronized statistics delivery
    • Flow identification based on hash keys
    • Dynamic hash key selection
    • Frame and flow filtering
    • Deduplication
    • Slicing
    • Intelligent multi-CPU distribution
    • Cache pre-fetch optimization
    • Coloring
    • IP fragment handling
    • Checksum verification
    • Checksum generation
    • GTP tunneling support
    • IP-in-IP tunneling support
    • Filtering inside tunnels
    • Slicing inside tunnels


    Всё это можно сделать и на других карточках. Просто надо потратить на это время.

    COMBO-80G



    image

    Скрытый текст
    • Virtex-7 FPGA chip manufactured by Xilinx company
    • 2× QSFP+ cage multi/single mode, CWDM or copper
    • 4× 10G to 40G fanout modules for 10G Ethernet technology
    • PCI Express 3.0 x8, throughput up to 50Gb/s to software
    • 2× 72Mbits QDRII+ SRAM memory
    • 2× 1152Mbits RLDRAM III memory
    • 2× 4GB DDR3 memory
    • External PPS (Pulse per second) synchronization
    • Unique on-the-fly FPGA boot system (no need for host computer reboot)


    Nallatech 385A и Nallatech 385C



    image

    Скрытый текст
    385A:

    • Arria 10 1150 GX FPGA with up to 1.5 TFlops
    • Network Enabled with (2) QSFP 10/40 GbE Support

    385C:

    • Altera Arria 10 GT FPGA with up to 1.5 TFlops
    • Network Enabled with (2) QSFP28 100 GbE support

    Общее:

    • Low Profile PCIe form factor
    • 8 GB DDR3 on-card memory
    • PCIe Gen3 x8 Host Interface
    • OpenCL tool flow


    Как видим, это два брата близнеца: в 385A стоит более бюджетная FPGA (GX) с трансиверами на 17.4 Gbps, что достаточно для 10/40G, а в 385С уже используется Arria 10 GT, т.к. нужны 28 Gpbs трансиверы для поддержки 100G, которые идут в исполнении 4x25G.

    Отмечу, что Nallatech предоставляет OpenCL BSP для этих карточек.

    HiTech Global 100G NIC



    image

    Скрытый текст
    • x1 Xilinx Virtex-7 H580T
    • x16 PCI Express Gen3 (16x8Gbps)
    • x1 CFP2 (4x25Gbps)
    • x1 CFP4 (4x25Gbps)
    • x1 Cypress QDR IV SRAM
    • x2 DDR3 SODIMMs (with support up to 16GB)
    • x4 Avago MiniPod (24 Tx and 24 Rx) for board-to-board high-speed communications
    • x1 FMC with 8 GTH transceivers and 34 LVDS pairs (LA0-LA33)


    Здесь мы наблюдаем и FMC разъем для подключения других плат, и Avago MiniPod, о котором говорили ранее.

    Бонус:


    Nallatech 510T



    image

    image

    В этой карточке нет Ethernet'a, но это реально бомба.

    Скрытый текст
    • GPU Form Factor Card with (2) Arria 10 10A1150GX FPGAs
    • Dual Slot Standard Configuration
    • Single Slot width possible, if user design fits within ~100W power footprint
    • PCIe Gen3 x 16 Host Interface
    • 290 GBytes/s Peak Aggregate Memory Bandwidth:
      • 85GB/s Peak DDR4 Memory Bandwidth per FPGA (4 Banks per FPGA)
      • 30GB/s Write + 30GB/s Read Peak HMC Bandwidth per FPGA


    Здесь и два жирных топовых чипа, которые клепаются по 20-нм технологии, и DDR4, и HMC. Производительность обещается до 3 TFlops!

    Судя по рендеру, до реальной железки там еще далеко, но чувствуется, что будет она золотой (по цене), но свою нишу займет: её позиционируют как сопроцессор для датацентров. Обещают поддержку OpenCL, а это значит, что никто до такта с этой платой нянчится не будет: загонят готовые алгоритмы и будут прожигать ватты. Кто знает, может на этой плате Youtube, Facebook, ВК будут конвертить видео, заменяя десятки серверов? Или может спецэффекты для нового Аватара будут рендерится на таких фермах?

    Заключение


    Посмотрев, на всё это разнообразие плат мы с коллегами подумали: почему бы нам тоже не сделать такую карточку?
    По сложности печатной платы она не будет сложнее чем B100, софт под FPGA и Linux писать мы вроде бы умеем, да и спрос у определенных компаний и ведомств есть на такие железки.

    Мы с коллегами немного спорили какую карточку делать, и нам интересно что вы думаете по этому поводу.

    Спасибо за внимание! Готов ответить на вопросы в комментариях или в личке.

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Какую карточку делать?
    Поделиться публикацией

    Похожие публикации

    Комментарии 56
      0
      (статью ещё не читал). Спасибо, КДПВ шикарна. Сначала подумал даже, что монтаж. DB-9 перпендикулярно плате впервые вижу. Да и контраст с SFP-cage смущает :-)
        0
        Значит у вас не так много опыта в поиске компонентов) У меня таких целый пакет валяется где то.
          +1
          Я вообще из другой оперы. Купила контора как-то раз тестер метротековский. И тут меня понесло :-)
            0
            мопед плата на кдпв — не наша. плату нашего 100 GbE дивайса автор статьи отказался выкладывать. дескать, на ней нет разъёма PCIe, несмотря на то, что обмен с управляющей системой по PCIe идёт.

            а тестер… что тестер? :)
        +6
        Я бы ещё добавил платы для тех кто хочет попробовать Ethernet на FPGA но не имеет возможности отдать больше 500$ за хобби.
        www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=139&No=746 (PCIe x1 + Ethernet 1Gb)
        www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=53&No=30 (хорошая плата с большим набором переферии однако старый чип(Cyclone II) и всего лишь 100Мегабит)
        www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=139&No=529&PartNo=2 (Необычная плата Intel Atom + Cyclon IV на обоих по гигабитному порту.)
          –7
          Вижу здесь явных пособников роскомнадзора.
            +8
            А в производителях ножей — пособников убийц?
              +4
              Как и пособников службы безопасности банков и других серьезных корпораций)
                +1
                На самом деле даже неприятный и мерзкий Роскомпозор неплохо продвинул сферу фильтрации вперед :)
              –1
              Почему нет варианта «не делать карточку»?

                +1
                У нас на работе вот такие, вместо обогревателей используем:


                Virtex7 2000T внутри. Но это для ASIC prototyping, не для телекоммуникаций.
                0
                Идея конечно стара. В свое время для обработки трафика народ пробовал использовать GPGPU и вполне неплохо получалось.
                  0
                  GPU — плохая идея, там шина очень узкая. Потому что нужно аж дважды прогнать трафик от NIC/PCIE к CPU, потом в GPU, потом вернуть по той же схеме и отправить в сеть. Не особо оптимальная тема выходит. Обработка без затрагивания шины PCIE наиболее приятный вариант :)
                    0
                    Давно уже не надо. У современных GPU есть DMA в полный рост. Так что они могут напрямую читать данные из сетевухи и обратно.
                      0
                      norguhtar А может видели проекты, где такое реализовано, интересно было бы посмотреть
                        0
                        Я ссылочку ниже дал. Там правда исследовательский проект, но никто не мешает его его утащить в продакшен.
                • НЛО прилетело и опубликовало эту надпись здесь
                    0
                    Вы вот, например, вспомнили про GPGPU, а что именно неплохо получалось не стали указывать. Предположим GPU помог кому-то распараллелить операции с плавающей точкой одинарной точности, а кроме биллинга есть здесь еще какая-то практическая польза?

                    Держите ссылочку
                    shader.kaist.edu/packetshader
                    Статья пятилетней давности, но в целом для понимания пойдет. И да причем тут биллинг? :) Это использовать можно для анализа и управления трафиком. Там знаете и целочисленных операций хватит.

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

                    Не их специализация. Ребята делают сетевые железки. До DPI доберутся постепенно :) Хотя сейчас DPI в малых масштабах до 10G отлично делается и на CPU.
                    +2
                    В проекте 100G анализатора и балансировщика возникли задачи, которые мы никогда не решали
                    Балансировщик-то сделали?
                      0
                      Естественно, сделали :)
                        0
                        Не смог у вас на сайте описание найти. Попросите ваших сейлов прислать мне на ivlad@yandex-team.com, если можно.
                          +1
                          отправил буклетик на указанный email.
                      0
                      Если говорить о примерах использования FPGA в big data, то есть классика — Netezza (ныне часть IBM), которые часть обработки осуществляют на FPGA. Непонятно, правда, почему вы в пункте про MS смешиваете highload и bigdata.
                        0
                        Офтопный вопрос, а сколько стоят курсы FPGA и когда они проводятся? :) Просто Ваш офис от меня через дорогу и не хочется упустить такую возможность =)
                          +2
                          А бесплатно: мы никаких сертификатов не выдаем, и никак не связаны с вендорами (официально, как, например, Политех).
                          Они позиционируется для студентов старших курсов, а не для серьезных дядечек)
                          0
                          Звучит очень интересно, но это же просто железо. То есть здорово, хорошо, но в реальной жизни не применимо.

                          Как оно поддерживается софтом? Каким софтом? Какие SDK/либы есть для работы с этим?

                          Могу я взять, например, программу на scapy и «скомпилировать» в код для FPGA?

                          И ещё, вопрос по железу: до какого уровня оно управляемое? Можно «своё» на phy слать, или SFP'шная часть сама по себе?
                            0
                            С одной стороны, это действительно просто железо, как, скажем процессор от Интела. Программы для него — это уже проблема разработчика.

                            Действительно для FPGA мало открытых либ, т.к. эта сфера очень специфичная. Кому надо либо покупают готовые IP-ядра (см. выше, где был пример про TCP/UDP ядра), либо пишут сами (заказывают у контор, которые пишут IP-ядра).

                            Для зашивки/разрботки программ на FPGA используются SDK от вендоров, разработчики плат предоставляет референсные дизайны/bsp.

                            Программу на scapy и скомпилировать в код в FPGA не сможете.

                            Без проблем управляемая до уровня XGMII, на более низком уже сложнее/невозможно.
                              +3
                              Интел делает очень много софта, чтобы это не было «проблемой разработчика». Есть и свой компилятор, и патчи в gcc, и в llvm, и патчи в ядро для поддержки новых фич процессора операционной системой.

                              Разработчик железа, который говорит «поддержка в софте это не мои проблемы» никогда не получит значительного рынка. См пример ардуинки, которая сама по себе никому не сдалась, если бы не студия.
                                0
                                Я не разработчик железа: я как раз пишу софт под FPGA, поэтому понимаю проблемы о которых вы говорите :)
                                  +1
                                  (продолжая)
                                  … а вот идея насчёт «easy fpga» у меня как раз зудит. Что-то очень казуальное и простое для программирования логики. Если под это дело будет свой высокоуровневый язык (пусть и не такой гибкий как «напрямую в бездну») и поддержка экосистемы вокруг — то просто конфетка получается.

                                  Например, модуль для iptables, реализующий их на аппаратном уровне на подобном железе. С руками же отрывать будут.

                                  Или аппаратно-программная поддержка туннелей/виланов силами fpga (читай, модуль ядра), анонсирующая в систему псевдосетевые адаптеры, которые можно использовать не глядя на обвязку.

                                  Конфетка же, а не применение.
                                    +2
                                    OpenCL — это высокоуровневый язык :)

                                    У Альтеры есть пример парсера 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.


                                    www.altera.com/support/support-resources/design-examples/design-software/opencl/opra-fast.html

                                    UDP оffload engine — это ядро, ссылку на который я давал ранее.

                                    Поэтому высокоуровне программировать FPGA можно. Насколько это будет эффективно в конкретной задаче — это другой вопрос.

                                    Многих пугает и останавливает большой ценник на такие платы с FPGA: от 4 до 15 тысяч долларов (и более).

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

                                    Если платы будут по 300$, то это наверно будет совершенно другой разговор, да и цена формируется же рынком)
                                      0
                                      Ценники на платы совсем не пугают, т.к. в промышленном смысле эти цены равны нулю. А вот тот факт что разработка идет в 10-100 раз медленнее (и соответственно дороже) чем банальный x86 — вот это как раз пугает.

                                      Вторая проблема — я не вижу хорошей IDE для того же VHDL. Непонятно как писать код без хорошего инструментария.
                                        +2
                                        В качестве IDE для написания кода под FPGA (Verilog), я использую vim. Особых проблем с этим не имею)

                                        По поводу медленнее расскажу пример из конкретной жизни:
                                        балансировка 100G -> 10x10G и 1000 правил фильтрации 100G linerate при уже имеющихся MAC-ядрах 100G и 10G у двух FPGA-разработчиков заняло месяц.

                                        Если это медленно и пугает, то я даже не знаю…
                                          +2
                                          Пример номер два:
                                          система мониторинга RTP-потоков, которую описывал мой коллега в habrahabr.ru/company/metrotek/blog/266561

                                          от FPGA требовалось парсить пакет (MAC/IP/UDP) на 10G, находить там RTP-данные, упаковывать в специальный бинарный формат, а затем упаковывать в UDP-пакеты и отправлять на 1G. При уже готовых 10G и 1G MAC-ядрах и готовой системе парсинга пакета от идеи до демонстрации на реальном трафике у оператора прошло две недели. Под FPGA пиcал один человек.

                                          Если и это медленно, то наверно мне надо начать медленее писать код)
                                            0
                                            Насчет IDE: VHDL беспощадный язык, в нем очень просто написать что-то что вообще не компилируется, а процесс компиляции (по крайней мере у меня в Quartus) — очень медленный. Конечно можно писать и в Notepad, я не спорю.
                                              0
                                              А у меня было такое что сложный проект состоящий из навороченной иерархии сворачивался после компиляции в 0 ячеек.
                                              Хотя там была общая шина, управляющие сигналы на кучу устройств на этой шине, сложная обработка. Многоуровневая вложенная иерархия с кучей арбитров по каждому устройству для каждой задачи.
                                              И общий арбитр шины всех устройств.
                                              Дак-вот, причина была в том что я взял библиотеки работающие в одинаковых фазах этого общего арбитра и квартус понял что они никогда не получат из-за этого доступ к шине и свернул всё в NULL. Подав на выходы константы.

                                              А время компиляции было подозрительно маленьким, минута вместо 10 мин и я сразу понял что-то не то.

                                              Так что если компилируется до безобразия быстро хотя должно долго — это отличный плюс самой среде.
                                              Да и просьба не забывать что в отличии от GCC компилятор квартуса смотрит общее взаимодействие всех модулей ко всем ко всем состояния во всей прошивке в целом, и благодаря этому отлично оптимизирует. А это важнее чем отладка через тестирование на железе с быстрыми итерациями, что в плис по-моему не уместно.
                                            0
                                            Кстати, почему-то Microsoft не пугает использовать FPGA и ставить их в 1632 сервера)

                                            Если очень надо, и без FPGA никак, а разработка занимает в 10 раз больше времени, то может тогда просто нанять 10 FPGA разработчиков? ;) Если это экономически невыгодно, то тогда просто не беритесь за эту задачу :)
                                              0
                                              Вспомнилось про девять женщин, которые должны были родить одного ребенка за месяц.)
                                              Нет, я понял что Вы абстрактно. Я не придираюсь, просто вспомнилось.
                                                0
                                                Непонятно где искать этих 10 разработичков. И да, точно так же как 9 женщин не сделают ребенка за месяц, совсем не файт что 10 разработчиков сделают продукт в 10 раз быстрее.
                                                  +2
                                                  Никто ж не плачет, что постройка АЭС — очень долго и дорого. А молча отстегивают бабло и ждут. Кому не нравится — жгут уголь (или строят ветряки). Тут примерно так же.
                                                +1
                                                Возвращаясь к вопросу, что медленно идёт разработка:

                                                PLDA предлагает использовать QuickPlay: http://www.quickplay.io/networking

                                                QuickPlay enables the rapid development of FPGA based network processing applications. With QuickPlay, networking equipment manufacturers can securely open up their FPGA designs to end users. End users can modify and tune vendor’s designs or create their own networking designs without ever requiring hardware skills.

                                                Демки, где в "удобной IDE" создается приложение с приёмом и отправкой данных на 10Gb интерфейс без Verilog'a:


                                  • НЛО прилетело и опубликовало эту надпись здесь
                                      +2
                                      это не черепаха на трёх китах,
                                      это даже хуже
                                      image

                                      у ПЛИС есть существенные минусы:
                                      1. Норма когда проект компилируется час или два, и потребляет 8-32 гигов озу на компиляцию.
                                      2. Решения или сырые или крайне сырые (нет даже нормальных примеров)
                                      3. Сама разработка под ПЛИС это не написание кода по шагам, а описание схемы в целом (это очень тяжело и чертовски долго).
                                      4. Сами производители не отстают от моды, маркетологи и дизайнеры лютуют: новая версия квартуса с редизайном UI и только она поддерживает новые чипы и это норма.
                                      5. Баги: иногда что то падает или мастер не вызывается. и это после 2-3 сервис пака и это норма и не считается нестабильной средой.
                                      (а особо весёлые сюрпризы уготовлены тем кто использует пути с кириллицей даже не явно — имя пользователя например в documents and settings)
                                      6. Быдлокод, очень адский, потому что каждый модуль не зависит от другого и всю систему целиком не уронит, плюс сумашедшая гонка чипов.
                                      7. Стоимость IP ядер за гранью разумного.
                                      8. Всякие мутные нюансы: шин нет а есть соединения всех ко всему с вытекающим жором ресурсов (если не учесть архетектуре), не самые оптимальные либы от производителей которые жрут в 2-3 раза больше и медленнее работают (будто заставляют брать пожирнее камень).
                                        +4
                                        про плюсы забыл, для меня плюсы такие:
                                        самый главный плюс это скорость и параллельность, это реально нечто, как будто вместо дискет 5 дюймовых на SSD пересел.

                                        ну и то что можно сделать многие вещи не прибегая к внешним IP на уровне описания что мне нужно от входов и как выхода зависят от входов и внутренних состояний — а компилятор как нибудь сам сделает реализацию.

                                        В ряде случаев на плис существенно быстрее разрабатывать электронику если можно обойтись своими силами не покупая готовые либы.

                                        Особенно нравится делать свою простую но специальную периферию для внешнего МК: существенно быстрее написать на плис реализацию хитрого таймера с запуском ацп и прочими фишками чем углубляться в дебри описания и конфигурирования того же STM32 и его таймеров — порой это экономия недель.
                                          +3
                                          Попробую защитить разработку под FPGA (применительно к Альтере, т.к. я пишу под неё).

                                          1. Да, это норма. Бывает и побольше. Когда мы делали анализатор/балансировщик 100G, то полная сборка с нуля занимала 5-6 часов. На самом деле это не так страшно, т.к. сборка производится очень редко (допустим, в конце недельного спринта, когда делается релиз прошивки), и, разумеется, делается ночью. Весь код предварительно прогоняется в симуляторе, где очень быстрая сборка (минута), отлаживается там же, и затем просто собирается квартусом. Очень редко что-то приходится смотреть сигналтапом (раз в квартал, наверно).

                                          2. Вы про BSP для девкитов?

                                          3. Это такое же программирование, как и любое другое: с предсказуемым временем на разработку. Есть небольшой свод правил, которым надо следовать и всё будет хорошо. Да, сортировку под FPGA надо писать с нуля день, а в C просто вызвать qsort, но таковы реалии. Кстати, попробуйте с нуля, никуда не подглядывая, написать сортировку на ассемблере, думаю тоже будет «тяжело и чертовски долго».

                                          4. Да, есть такой минус.

                                          5. За четыре года работы я видел только три бага квартуса. Не знаю, это много или нет. Не забываете, что пользователей gcc в десятки тысяч раз больше, чем пользователей квартуса. Ну, а проблемы с кириллицей и documents and settings мне не знакомы — я на linux'e сижу)

                                          6. Наличие быдлокода зависит очень о того, кто пишет) Да, иногда не самые оптимильные по количеству строк решения вылезают из-за ограничения языка, который используется. Но есть у вас в проекте быдлокод, это значит, что тот код делает ревью, делает это неправильно, или сам пишет быдлокод (как и в любом другом языке). Не очень понял про независимость модулей и про сумасшедшую гонку чипов.

                                          7. Да, дорогие, потому что разработка под FPGA это «тяжело и чертовски долго» :).

                                          8. Да, такое встречается. Зависит от специфики проектов/IP-ядер.
                                            +2
                                            2. Вы про BSP для девкитов?

                                            и про BSP и про всё в целом, выходят например макс5, ок, покупаешь отладку их, всё работает, но в реальной работе мало приминимо и выплёвывается как обычно стопятьсот варнингов, а порой тыща. Понимаешь что попал на огромную кучу программных и аппаратных нюансов. Пишешь в саппорт «да да скоро исправим», и всё, через пару лет «покупайте макс 10». Я понимаю что это только по сути демоплата и ожидать с неё нечего, но блин дорабатывать железо и как то развивать софт надо а не просто выпускать новый чип и новые особенности и баги фичи.

                                            3. Это такое же программирование, как и любое другое: с предсказуемым временем на разработку.

                                            У меня всё норм, а вот те кому я пытался это дело передать и обучить — было очень плохо и долго. Даже если человек сразу слёту рулит в сигнальной обработке и может накатать алгоритм детекции женского голоса например, а вот в плис вообще никак. Так что я думаю мы с тобой братья по складу ума и не всем дано.

                                            6. Быдлокод внутри либ квартуса (особенно в AHDL) и сторонних либ, его почему то больше чем в обычных исходниках на си или с++. Возможно из за цены бага — они существенно меньше в FPGA. На некоторых либах workaround: reset before send eatch packet

                                            5. Блин, чертовски завидиую, а у нас фирма упёрлась в винду и не хотят своё оборудование никчему другому адаптировать — кое как сделали для люникса «порт» (под вайном) и… забросили.
                                              +3
                                              На самом деле FPGA в этом смысле проще, чем процессор. Потому как тут все создаешь сам с нуля и сам себе царь и бог. Настоящие ошибки в софте или «железе» FPGA, нарушающие функциональность, встречаются крайне редко. Хуже когда приходится подлючать сторонние ip-компоненты, и чем сложнее его интерфейс, тем больше сомнений в себе и окружающем мире ;)
                                              Но по сравнению с запуском банального SPI на каком-нибудь многоядерном монстре (коллега тут мучался. долго) по невнятной документации TI — не так и страшно.
                                              Но стоимость отладки багов, конечно, значительно больше.
                                                +1
                                                Потому как тут все создаешь сам с нуля и сам себе царь и бог.

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

                                                Я использую для телефонии FPGA и CPLD в связке с 32битными ARM MCU серии STM32F103 или STM32F405. Подключается МК по шине внешней памяти FSMC. В итоге процессор получает уже готовые массивы байт, с пойманной синхронизацией и проверенным CRC. И на процессоре остаётся только делать уже то, что на проце проще делать — работа с звуком и обработка сигнализации, коммутации и прочие самые высокоуровневые вещи. Те вещи которые как раз и надо менять чаще всего.

                                                Да интересный момент есть — я закладываю обычно ещё возможность обновления прошивки ПЛИС самим клиентом, но это не разу не понадобилось делать. А вот обновление прошивки у STM — это постоянно (раз в несколько месяцев).
                                        +2
                                        Риквестую статьи про FPGA с минимальным порогом входа :) Мне из софтварного мира крайне сложно разобраться с сабжем без возможности потрогать руками на недорогом девките :(
                                          0
                                          Таки было-же, и на хабре в своё время, и вроде как существует по ныне вот такой marsohod.org замечательный проект.
                                          Всем советую, ибо сейчас люди в FPGA за деньгами приходят, взрослые разработчики, книжек начитаются и сразу начинают делать проекты из готовых блоков, не сильно вдаваясь в их внутреннее устройство и идеологию разработки, а она совершенно ИНАЯ!
                                          0
                                          Этот весь анализ данных, что описан в статье делается без Microblaze?
                                            +1
                                            Я в статье рассказал про карточки от различных вендоров, их ТТХ, а так же общий обзор: что туда запихивают из железа.

                                            Кто и как их использует — это сумма того, что я видел в интернете, какие запросы на разработку к нам приходят, а так же общение с коллегами из других фирм. А использует ли кто-то [в мире] для этих задач Microblaze или нет — я не знаю.

                                            Когда мы решаем эти (или похожие) задачи на своих железках (они с FPGA, но без PCIe) — мы не используем NIOS/Microblaze, потому что когда ты хочешь фильтровать 5-tuple или LPM на linerate 10G/40G/100G, то, боюсь, производительности софтового проца не хватит. Возможно для какого-то более глубокого анализа и можно его применить, не знаю.
                                              0
                                              На 40GE еще можно в софте, если найти сетевые которые его выжмут. Софту — это не проблема. Проблема как раз на моменте сопряжения проца и эзернета. А вот сотка — безальтернативно :)
                                            0
                                            Мне всегда нравилась разработка под FPGA разных сетевых проектов, но в последнее время стал сильно думать прежде чем связываться еще.
                                            Развитие современных процов и разных модулей для Линукс для работы с сетью сильно повысили возможности и производительность систем на базе х86. И я сейчас не касаюсь DPDK или решений от 6wind.
                                            Как-то решения на базе FPGA становятся все более и более узкоспециализированные. Найти толковых разработчиков ПЛИС все сложнее и сложнее, девкиты дорогие и достать не всегда просто, отладка сложнее, переносимость кода не супер.
                                              0
                                              DPDK и прочие имеет множество проблем как раз на стороне сетевых карт. 40GE мир — вообще «табу» для всяких там 6WIND и DPDK. Про 100GE я даже не заикаюсь :)
                                                0
                                                Согласен, что 40+ это прерогатива ПЛИС и асиков. Вот, то что ниже 10-ки, тут надо уже хорошо думать как делать.

                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                            Самое читаемое