Юрий, спасибо за статью. Хотел у Вас спросить о преимуществе конвейера с кредитным счетчиком? Ведь возможны более простые варианты организации конвейера, например такой:
>Поэтому конкуренции как таковой нет и заниматься этим нет смысла
Конкуренции нет потому что государство тратит огромные деньги на подготовку студентов по гуманитарным специальностям в вузах. Как по мне, так еще более бессмысленная вещь чем обучение студентов line-rate обработке ethernet потоков на FPGA.
Сам репозиторий — вендорнезависимый, можно реализовывать как на Xilinx так и на Altera. Язык (Verilog), шина между корками — AXI4-stream.
Сам лично, в последнее время особенно, все больше имею дело с Интелом (в том числе с Arria 10GX). PAC в основном позиционируется как коробочное решение для датацентров (под разработку в OpenCL, OpenVINO). Тем не менее, работа с Arria10 внутри PAC из Quartus напрямую возможна.
Это не совсем импортозамещение софта, это импортозамещение (IP-cores) для создания сетевого оборудования.
Глядя на Verilog-RTL, можно схему хоть из «советских» транзисторов спаять.
>Количество специалистов умеющих в FPGA сравнительно невелико
Увы в России, это так.
>задачи сетевой обработки — это достаточно малая часть от всех задач, решаемых на FPGA
Согласен задачи достаточно специфичны, но общие принципы проектирования систем на FPGA схожи (конвейеры, конечные автоматы, протоколы шин данных и тд).
>Не очевидна мотивация, которая побудит их делать достаточно сложную работу бесплатно, если можно делать её же за деньги.
Проекты на Github могут хорошо дополнить резюме например или выступать в качестве портфолио разработчика.
Ну здесь опять вопрос — стакан на половину полон или наполовину пуст? Циска и джунипер ведь тоже используют FPGA сторонних производителей?
Тем не менее, я ни в коем случае не пытаюсь сказать, что монополизация рынка FPGA в том виде в котором она существует сегодня — это хорошо.
Да принимаем фрейм целиком — классический «store-and-forward».
(Кольцевой) буфер на 2-3 фрейма даст вам лучшую производительность — маркировка и обработка очереди у вас уже, судя по презентации, в каком-то виде есть.
Или соль в том, что вы декодируете заголовок входящего потока на лету, помещая фрейм в буфер с пред-созданным заголовком (mpls, GRE, IPIP)?
Используется кольцевой буфер на 4фрейма каждый максимальным размером 2048 байт.
Декодировки фрейма на лету нет, но при буфферизации фрейма в отдельные регистры записываются номер vlan и в конце значение счетчика длины принятого фрейма.
После просмотра видео очередной вопрос на перфоманс: вы измеряли внесённую задержку с подходом «положи весь фрейм в буфер, обменяйся сигналами с блоками приёма и обработки, дождись обработки фрейма»?
Обработки фрейма и обмена сигналами после приема фрейма нет. Сразу после приема фрейма уже имеются все данные для генерации правильного заголовка (так как номер vlan уже увляется указателем на память с заголовком из которой сразу же можно считывать данные для L3 заголовка).
Ну и сам исходный буфферизованный фрейм уже имеется сохраненным в другом блоке памяти.
На выходе системы стоит мультиплексор который склеивает (направляет данные из генератора L3 заголовоков и как L3 заголовок закончился переключается на память где хранится исходный фрейм).
Задержка обработки в некотором роде связана с глубиной буферизации на входе. Какие ресурсы по памяти предоставляет вам FPGA?
В данной реализации фреймовый кольцевой буффер построен на ячейке SRAM размером 8192байта достаточной для буфферизации четырех фреймов каждый максимальным размером 2048 байт.
Будете ли вы использовать внешнюю память, если-когда памяти на чипе вам не хватит?
В FPGA таких SRAM ячеек тысячи, из маленьких можно комбинировать бОльшую память (если нужнен буффер на 16, 32 или 64 фрейма).
Внешняя память это DDR DRAM, в FPGA ее нет (она как правило внешняя) и она нам не нужна.
Верилог я не пойму :) В любом случае, верилог — это реализация концепции, мне интереснее сама концепция.
Верилог — дело десятое. Важно понять то, что хардварный дизайн более схож с дизайном водопроводных систем (я не шучу), где много всего происходит одновременно, чем с традиционным линейным программированием :-)
И как вы правильно сказали «колцевые буфферы» — наше все.
Посмотрите документацию на проект “EtherBlade.net Ver1”, там есть pdf-ка — в ней более детально расписано то что я изложил здесь.
Если интересно, про устройство кольцевого буффера на основе SRAM посмотрите документацию на “EHA – Ethernet Hardware Encapsulator” – legacy project (версия первая).
Опять же для разработки control-plane все это дело абстрагируется до блоков адресов для программирования data-path.
Я кстати хотел написать в третей части статьи и уточнить что etherblade.net это по сути только репозиторий схем (IP-cores) — для построения hardware plane.
Целью проекта не является создание конечной системы. То есть создание обвязки — системы на чипе, портирование на FPGA платы, написание embedded management software которое будет коммуницировать с SDN контроллером, создание которого так же выходит за рамки данного проекта — предполагается отдать на разработку в комьюнити.
На самом деле etherblade.net это только 5-10% работы, оставшиеся 90% это сигналинг написание софта, интеграция, портирование, тестирование (все, что не Verilog).
Как предписывает концепция SDN, программисты и разработчики железа работают отдельно и делают свои части (определили интерфейс взаимодействия софта и железа и вперед).
Модуль вам все равно понадобится, если вы решите пойти дальше экспериментов по изменению пакетов.
Да, можно даже взять FPGA с третьим интерфейсом (CycloneV например) с хардварной ARM процессорной частью и линуксом и как Вы абсолютно правильно говорите отдельным out-of-band management ethernet интерфейсом. Опять же портирование на платы хотелось бы вынести за рамки проекта.
Абсолютно никакого — через некоторое время (при полном заполнении буфера) начнутся dropped frames на входном интерфейсе при достижении пиковой пропускной способности выходного интерфейса.
tcp — саморегулируемый протокол, он начинает разгоняться с нуля и при первых дропах (возникающих в самом узком месте сети я не думаю что 10гигабитный инкапсулятор часто будет таковым являться) начинает «сбрасывать газ».
В любом случае хардварному буферу не интересно какой там пакет. Его заботит только один параметр — номер vlan входящего ethernet фрейма.
Почему будут просадки по tcp? Инкапсулятор не будет даже знать что у него там за пакет. Это ведь по сути дела хардварный буфер с некоторой логикой прикрепления заголовков из памяти в зависимости номера VLAN. В инкапсуяторе нет TCP/IP стека, тем не менее инкапсулировать ethernet в IPv4/IPv6 он умеет если в памяти адресуемой данным номером влана прописан заголовок формата IPv4/IPv6.
Это очень интересно.
Вообще сам процесс синтезирования RTL (читай Verilog/VHDL) и портирования его на FPGA, создание системы на кристалле и тестирования всего этого дела в работе интереснейшее занятие.
Похоже пора создавать форум, выкладывать гайды по портированию и ждать результатов тестов от community. Помню в СССР был журнал радио где выкладывалась схема, которую паяли у себя дома, тестировали и в следующих журналах делились мнениями и необходимыми доработками.
Сегодня есть FPGA так что можно делать чипы не отходя от лаптопа.
Денис приветствую,
Для простоты перехода от гигабита на десять можно договориться что L3 заголовок всегда кратный 8 байтам (64битам) что бы избежать misalignment между заголовком и телом пакета при их склеивании на выходе мультиплексором.
В этом случает потребуется 8-to-64bit gearbox между восьмибитным выходом генератора заголовка и 64 битным выходящим мультиплексором. Генератор заголовков все равно останется восьмибитныйм, поэтому пока отправляется тело предыдущего пакета одновременно с этим уже идет генерация следующего заголовка и его упаковка в 64битный формат для конечной отправки.
При дальнейшем расширении шины я боюсь что восьмибитный генератор заголовков не будет успевать их генерировать и упаковывать в 64бита (со скоростью байт за такт) пока отправляется предыдущий пакет со скоростью 64 байта за такт то есть выходная скорость будет падать так как слишком большая разница между компонентами.
В коммутаторах такой проблемы нет так как они не меняют сам фрейм то есть им все равно какая шина (хоть 512), они одинаковыми порциями загребают такими же порциями и выбрасывают на выходе.
Например, как-где происходит выделение буферов, как устроен QoS в целом и частностях
С QoS не заморачиваюсь поскольку это pseudowire устройство всего с двумя интерфейсами работает по принципу «первый пришел первый вышел» — switchfabric congestion отсутствует так как нет этого самого switchfabris и, к слову, mac-learning тоже нет.
есть ли микробуферизация, на какие части делите пакет, как склеиваете обратно. Это вот прямо то, что очень интересно лично мне :-)
По сути дела инкапсулятор это фреймовый буфер (на данный момент он на 4 фрейма размером 2048байт каждый).
Разделение пакета это Вы имеете в виду фрагментацию? Фрагментация в разработке в другой части проекта. Самая сложная чась — склейка фрагментированных фрагментов. Демонстрация принципа алгоритма склейки фрагментов в железе без участия софта здесь.
К вопросу на счет внутреннего устройства на сайте есть раздел «documentation» там есть документация и исходный Verilog. Боюсь что лучше чем там написано я сейчас не смогу объяснить.
Содержимое аидео функционально похоже на OpenFlow устройство без контроллера. Самое сложное как в OpenFlow, так и в MPLS (как и в IP-маршрутизации в целом) — сигналинг.
Для лабораторного сценария (быстрый колхозный вариант) можно взять raspberry-pi которая будет общаться с SDN-контроллером через по протоколу IP а с другой стороны прописывать необходимые заголовки в FPGA для разных вланов через com-port. Это простой pseudowire overlay там сигналинга нет, нужет только начальный provisioning L3 заголовков.
Верно все как на коммутаторах — 100% загрузка буфера инкапсулятора вызовет buffer-overflow на входящем FIFO и данные фреймы будут промаркированы как «битые» и отброшены инкапсулятором.
Можно сделать инкапсулятор с более глубокой буфферизацией (на 32 ethernet фрейма вместо четырех) для лучшей обработки burst-траффика.
Планируем получить 10Gb ethernet line-rate speed как в ethernet коммутаторах.
Размер пакетов тут особой роли не играет (ну почти не играет у каждого фрейма ведь есть — избыточная преамбула ethernet, inter-frame-interval, CRCs).
FPGA в силу своей конфигурационной гибкости достаточно ограничена по тактовой частоте в силу избыточной логики, особенно на коммутационных блоках. Для построения систем со скоростями 10гигиабит — FPGA подойдет. Та так же FPGA — отличный вариант для тестирования и отладки схем. Все что выше по скоростям — делаем из отлаженных на FPGA схем ASIC.
В опенсорсе как таковом уже есть baremetal коммутаторы (например, bm-switch.com).
Но ведь сами внутренности коммутирующего ASICа закрыты, правильно?
Под опенсорс-ом здесь понимается то что система комманд программирования чипа открыта но не сами «внутренности» чипа.
Если я не прав дайте ссылку на RTL ASICa плиз, я как вижу там используется StrataXGS Tomahawk от BroadCom.
Юрий, спасибо за статью. Хотел у Вас спросить о преимуществе конвейера с кредитным счетчиком? Ведь возможны более простые варианты организации конвейера, например такой:
Конкуренции нет потому что государство тратит огромные деньги на подготовку студентов по гуманитарным специальностям в вузах. Как по мне, так еще более бессмысленная вещь чем обучение студентов line-rate обработке ethernet потоков на FPGA.
Сам лично, в последнее время особенно, все больше имею дело с Интелом (в том числе с Arria 10GX). PAC в основном позиционируется как коробочное решение для датацентров (под разработку в OpenCL, OpenVINO). Тем не менее, работа с Arria10 внутри PAC из Quartus напрямую возможна.
Глядя на Verilog-RTL, можно схему хоть из «советских» транзисторов спаять.
Увы в России, это так.
>задачи сетевой обработки — это достаточно малая часть от всех задач, решаемых на FPGA
Согласен задачи достаточно специфичны, но общие принципы проектирования систем на FPGA схожи (конвейеры, конечные автоматы, протоколы шин данных и тд).
>Не очевидна мотивация, которая побудит их делать достаточно сложную работу бесплатно, если можно делать её же за деньги.
Проекты на Github могут хорошо дополнить резюме например или выступать в качестве портфолио разработчика.
Тем не менее, я ни в коем случае не пытаюсь сказать, что монополизация рынка FPGA в том виде в котором она существует сегодня — это хорошо.
Да принимаем фрейм целиком — классический «store-and-forward».
Используется кольцевой буфер на 4фрейма каждый максимальным размером 2048 байт.
Декодировки фрейма на лету нет, но при буфферизации фрейма в отдельные регистры записываются номер vlan и в конце значение счетчика длины принятого фрейма.
Обработки фрейма и обмена сигналами после приема фрейма нет. Сразу после приема фрейма уже имеются все данные для генерации правильного заголовка (так как номер vlan уже увляется указателем на память с заголовком из которой сразу же можно считывать данные для L3 заголовка).
Ну и сам исходный буфферизованный фрейм уже имеется сохраненным в другом блоке памяти.
На выходе системы стоит мультиплексор который склеивает (направляет данные из генератора L3 заголовоков и как L3 заголовок закончился переключается на память где хранится исходный фрейм).
В данной реализации фреймовый кольцевой буффер построен на ячейке SRAM размером 8192байта достаточной для буфферизации четырех фреймов каждый максимальным размером 2048 байт.
В FPGA таких SRAM ячеек тысячи, из маленьких можно комбинировать бОльшую память (если нужнен буффер на 16, 32 или 64 фрейма).
Внешняя память это DDR DRAM, в FPGA ее нет (она как правило внешняя) и она нам не нужна.
Верилог — дело десятое. Важно понять то, что хардварный дизайн более схож с дизайном водопроводных систем (я не шучу), где много всего происходит одновременно, чем с традиционным линейным программированием :-)
И как вы правильно сказали «колцевые буфферы» — наше все.
Посмотрите документацию на проект “EtherBlade.net Ver1”, там есть pdf-ка — в ней более детально расписано то что я изложил здесь.
Если интересно, про устройство кольцевого буффера на основе SRAM посмотрите документацию на “EHA – Ethernet Hardware Encapsulator” – legacy project (версия первая).
Опять же для разработки control-plane все это дело абстрагируется до блоков адресов для программирования data-path.
Целью проекта не является создание конечной системы. То есть создание обвязки — системы на чипе, портирование на FPGA платы, написание embedded management software которое будет коммуницировать с SDN контроллером, создание которого так же выходит за рамки данного проекта — предполагается отдать на разработку в комьюнити.
На самом деле etherblade.net это только 5-10% работы, оставшиеся 90% это сигналинг написание софта, интеграция, портирование, тестирование (все, что не Verilog).
Как предписывает концепция SDN, программисты и разработчики железа работают отдельно и делают свои части (определили интерфейс взаимодействия софта и железа и вперед).
Да, можно даже взять FPGA с третьим интерфейсом (CycloneV например) с хардварной ARM процессорной частью и линуксом и как Вы абсолютно правильно говорите отдельным out-of-band management ethernet интерфейсом. Опять же портирование на платы хотелось бы вынести за рамки проекта.
В любом случае хардварному буферу не интересно какой там пакет. Его заботит только один параметр — номер vlan входящего ethernet фрейма.
Вообще сам процесс синтезирования RTL (читай Verilog/VHDL) и портирования его на FPGA, создание системы на кристалле и тестирования всего этого дела в работе интереснейшее занятие.
Похоже пора создавать форум, выкладывать гайды по портированию и ждать результатов тестов от community. Помню в СССР был журнал радио где выкладывалась схема, которую паяли у себя дома, тестировали и в следующих журналах делились мнениями и необходимыми доработками.
Сегодня есть FPGA так что можно делать чипы не отходя от лаптопа.
Для простоты перехода от гигабита на десять можно договориться что L3 заголовок всегда кратный 8 байтам (64битам) что бы избежать misalignment между заголовком и телом пакета при их склеивании на выходе мультиплексором.
В этом случает потребуется 8-to-64bit gearbox между восьмибитным выходом генератора заголовка и 64 битным выходящим мультиплексором. Генератор заголовков все равно останется восьмибитныйм, поэтому пока отправляется тело предыдущего пакета одновременно с этим уже идет генерация следующего заголовка и его упаковка в 64битный формат для конечной отправки.
При дальнейшем расширении шины я боюсь что восьмибитный генератор заголовков не будет успевать их генерировать и упаковывать в 64бита (со скоростью байт за такт) пока отправляется предыдущий пакет со скоростью 64 байта за такт то есть выходная скорость будет падать так как слишком большая разница между компонентами.
В коммутаторах такой проблемы нет так как они не меняют сам фрейм то есть им все равно какая шина (хоть 512), они одинаковыми порциями загребают такими же порциями и выбрасывают на выходе.
С QoS не заморачиваюсь поскольку это pseudowire устройство всего с двумя интерфейсами работает по принципу «первый пришел первый вышел» — switchfabric congestion отсутствует так как нет этого самого switchfabris и, к слову, mac-learning тоже нет.
По сути дела инкапсулятор это фреймовый буфер (на данный момент он на 4 фрейма размером 2048байт каждый).
Разделение пакета это Вы имеете в виду фрагментацию? Фрагментация в разработке в другой части проекта. Самая сложная чась — склейка фрагментированных фрагментов. Демонстрация принципа алгоритма склейки фрагментов в железе без участия софта здесь.
К вопросу на счет внутреннего устройства на сайте есть раздел «documentation» там есть документация и исходный Verilog. Боюсь что лучше чем там написано я сейчас не смогу объяснить.
Для лабораторного сценария (быстрый колхозный вариант) можно взять raspberry-pi которая будет общаться с SDN-контроллером через по протоколу IP а с другой стороны прописывать необходимые заголовки в FPGA для разных вланов через com-port. Это простой pseudowire overlay там сигналинга нет, нужет только начальный provisioning L3 заголовков.
Можно сделать инкапсулятор с более глубокой буфферизацией (на 32 ethernet фрейма вместо четырех) для лучшей обработки burst-траффика.
Размер пакетов тут особой роли не играет (ну почти не играет у каждого фрейма ведь есть — избыточная преамбула ethernet, inter-frame-interval, CRCs).
Но ведь сами внутренности коммутирующего ASICа закрыты, правильно?
Под опенсорс-ом здесь понимается то что система комманд программирования чипа открыта но не сами «внутренности» чипа.
Если я не прав дайте ссылку на RTL ASICa плиз, я как вижу там используется StrataXGS Tomahawk от BroadCom.