Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 56
А Вы точно уверены, что
Что то мне кажется, что специализированные приемопередатчики в МПС дешевле и меньше едят, чем синтезированные, или надо брать FPGA с готовыми сетевыми блоками.
В качестве бонуса добавим сюда меньшее электропотребление и меньшую стоимость FPGA решений по сравнению с микропроцессорными системами.
Что то мне кажется, что специализированные приемопередатчики в МПС дешевле и меньше едят, чем синтезированные, или надо брать FPGA с готовыми сетевыми блоками.
Сейчас делаю проект на Zynq 7045 (система на кристалле от Xilinx). В РФ чипы продают по цене порядка 30 т.р. SFP+ трансивер (и даже не один) можно подключить к выводам SoC без необходимости использовать какие-либо микросхемы физического уровня. Бонусом получаете двухъядерный процессор и возможность обработки потока данных на ПЛИС. Не думаю, что получится сэкономить используя МПС.
Бонусом получаете двухъядерный процессор и возможность обработки потока данных на ПЛИС.
Причём можно в FPGA вытащить из процессора вычислительно-критичный кусок С-кода без написания HDL-я при помощи волшебного софта Xilinx SDx. Хотя всё равно нужно понимать, что делаешь но это быстрее чем HDL писать и фиксить.
Скажите, что Вы имеете в виду под специализированными приемопередатчиками в МПС? Маршрутизатор с network-ASICs на линейных картах?
Позвольте пару вопросов:
1)Почему именно Intel?
2)Существует ли возможность посмотреть на layout этой борды?
3)Не думали замахнуться на большие скорости(в т.ч. существенно большие)?
4)Как подбирали декапы под циклоном?
1)Почему именно Intel?
2)Существует ли возможность посмотреть на layout этой борды?
3)Не думали замахнуться на большие скорости(в т.ч. существенно большие)?
4)Как подбирали декапы под циклоном?
Тоже интересны ответы на вопросы.
1. Проект является репозиторием схем и по сути вендор-независимый. Можно портировать как на Intel так и на Xilinx.
2. Pinout всегда идет вместе с FPGA платой — иначе как с ней работать если не знать к каким «ножкам» какая периферия подключена?
3. Десять гигабит похоже на скорость близкую к максимальной для FPGA. Тем не менее из FPGA можно «выпечь» ASIC способный работать на большей тактовой частоте/скорости (40 и 100Гигабит) — ну тут уже все гораздо серьезней становится именно с финансовой точки зрения.
4. Подбор «декапов» это скорее вопрос к разработчикам платы.
2. Pinout всегда идет вместе с FPGA платой — иначе как с ней работать если не знать к каким «ножкам» какая периферия подключена?
3. Десять гигабит похоже на скорость близкую к максимальной для FPGA. Тем не менее из FPGA можно «выпечь» ASIC способный работать на большей тактовой частоте/скорости (40 и 100Гигабит) — ну тут уже все гораздо серьезней становится именно с финансовой точки зрения.
4. Подбор «декапов» это скорее вопрос к разработчикам платы.
Можно на QSFP замахнуться и выжать 40GbE, можно застрелить жабу, пролюбить сроки и замахнуться на Stratix с его трансиверами (там уже вроде 100GbE получить можно).
FPGA в силу своей конфигурационной гибкости достаточно ограничена по тактовой частоте в силу избыточной логики, особенно на коммутационных блоках. Для построения систем со скоростями 10гигиабит — FPGA подойдет. Та так же FPGA — отличный вариант для тестирования и отладки схем. Все что выше по скоростям — делаем из отлаженных на FPGA схем ASIC.
Arria 10 вроде вполне переваривает 40GbE, а с десятым стратиксом пришел новый интерконнект, который сделан весьма подходящим для построения конвеера и разбивания комбинаторики и как следствие задирание частоты работы бЭсплатно для разработчика (можно где-то на 5-10% частоту повысить установкой одной единственной галочки, а далее руками, у интеловцев на эту тему онлайн обучалка есть весьма недурная). По ценнику — для мелкой серии ПЛИС будет всеж дешевле, чем заказной кремний, правда сейчас привезти в РФ стратиксы почти нереально.
Вот всё-таки не понял, почему вы FPGA ограничили 10Гб/с или это ограничения вашей реализации? Вон у xilinx есть корки для 40 и 100Гб для представителей 7 серии. Насколько понимаю реализовано это через GTX/GTH трансиверы. А по поводу частот, у них там просто широкие шины внутри, судя по рисункам, 128 или 256 бит.
Прошу уточнить что именно будет open и под какой лицензией?
Задача крайне важная, но вечно натыкающаяся на то, что L3 — это не L2. Вот я вижу энкапсуляцию (для простоты обсуждения, 10.0.0.1). Почему 10.0.0.1? Откуда там 10.0.0.1 (а не 192.168.2.3, например)? Предполагается, что где-то там наверху кто-то из множества таких устройств соберёт бридж на центральном сервере? Как конкретная железка стала понимать, что 10.0.0.1, а не что-то другое и по какому признаку оно его меняет?
И главный вопрос: а где оно физически находится? Болтается на линке между клиентским портом и портом провайдера? (Со своим БП и прочими неудобствами?).
И главный вопрос: а где оно физически находится? Болтается на линке между клиентским портом и портом провайдера? (Со своим БП и прочими неудобствами?).
FMC-бутерброд по толщине прекрасно вписывается в 1U, также существует огромное множество отладочных плат под FPGA с 2-4 SFP либо 2 QSFP в PCI/PCIe форм-факторе.
Предлагаю Вам посмотреть видео демонстрирующее инкапсулятор в действии:
Ссылка на видео.
Первая часть видео рассказывает об архитектуре инкапсулятора, а вторая демонстрирует его в действии. Принцип простой, в памяти хранятся L3 заголовки которыми инкапсулируются входящие L2 ethernet фреймы — то есть происходит преобразование (L2->L3).
Если необходимо, видео сопряжено английскими субтитрами, а при необходимости в «Youtube» имеется опция включения автоперевода на русский язык.
На приемном инкапсуляторе происходит обратное преобразование (L3->L2) которое делает из L3 исходный L2 фрейм (то есть просто игнорируются первые N-байт равные длине L3 заголовка). Если не требуется сборка фрагментированных фрагментов — логика преобразования (L3->L2) чрезвычайно проста.
Ссылка на видео.
Первая часть видео рассказывает об архитектуре инкапсулятора, а вторая демонстрирует его в действии. Принцип простой, в памяти хранятся L3 заголовки которыми инкапсулируются входящие L2 ethernet фреймы — то есть происходит преобразование (L2->L3).
Если необходимо, видео сопряжено английскими субтитрами, а при необходимости в «Youtube» имеется опция включения автоперевода на русский язык.
На приемном инкапсуляторе происходит обратное преобразование (L3->L2) которое делает из L3 исходный L2 фрейм (то есть просто игнорируются первые N-байт равные длине L3 заголовка). Если не требуется сборка фрагментированных фрагментов — логика преобразования (L3->L2) чрезвычайно проста.
Небольшой совет: интуитивно принято заголовки (особенно если вы говорите prepend) приклеивать перед фреймом.
Содержимое аидео функционально похоже на OpenFlow устройство без контроллера. Самое сложное как в OpenFlow, так и в MPLS (как и в IP-маршрутизации в целом) — сигналинг.
Раз у вас есть такая демка, расскажите, как устроены потроха? Например, как-где происходит выделение буферов, как устроен QoS в целом и частностях, как организована «сеть» внутри устройства: есть ли микробуферизация, на какие части делите пакет, как склеиваете обратно. Это вот прямо то, что очень интересно лично мне :-)
Содержимое аидео функционально похоже на OpenFlow устройство без контроллера. Самое сложное как в OpenFlow, так и в MPLS (как и в IP-маршрутизации в целом) — сигналинг.
Раз у вас есть такая демка, расскажите, как устроены потроха? Например, как-где происходит выделение буферов, как устроен QoS в целом и частностях, как организована «сеть» внутри устройства: есть ли микробуферизация, на какие части делите пакет, как склеиваете обратно. Это вот прямо то, что очень интересно лично мне :-)
Содержимое аидео функционально похоже на OpenFlow устройство без контроллера. Самое сложное как в OpenFlow, так и в MPLS (как и в IP-маршрутизации в целом) — сигналинг.
Для лабораторного сценария (быстрый колхозный вариант) можно взять raspberry-pi которая будет общаться с SDN-контроллером через по протоколу IP а с другой стороны прописывать необходимые заголовки в FPGA для разных вланов через com-port. Это простой pseudowire overlay там сигналинга нет, нужет только начальный provisioning L3 заголовков.
ком-портом вы себя сильно ограничиваете — не сейчас, так в перспективе. Не хотите прикрутить третий эзернет на гиг для управления? Модуль вам все равно понадобится, если вы решите пойти дальше экспериментов по изменению пакетов.
Я кстати хотел написать в третей части статьи и уточнить что 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 интерфейсом. Опять же портирование на платы хотелось бы вынести за рамки проекта.
Целью проекта не является создание конечной системы. То есть создание обвязки — системы на чипе, портирование на FPGA платы, написание embedded management software которое будет коммуницировать с SDN контроллером, создание которого так же выходит за рамки данного проекта — предполагается отдать на разработку в комьюнити.
На самом деле etherblade.net это только 5-10% работы, оставшиеся 90% это сигналинг написание софта, интеграция, портирование, тестирование (все, что не Verilog).
Как предписывает концепция SDN, программисты и разработчики железа работают отдельно и делают свои части (определили интерфейс взаимодействия софта и железа и вперед).
Модуль вам все равно понадобится, если вы решите пойти дальше экспериментов по изменению пакетов.
Да, можно даже взять FPGA с третьим интерфейсом (CycloneV например) с хардварной ARM процессорной частью и линуксом и как Вы абсолютно правильно говорите отдельным out-of-band management ethernet интерфейсом. Опять же портирование на платы хотелось бы вынести за рамки проекта.
Например, как-где происходит выделение буферов, как устроен QoS в целом и частностях
С QoS не заморачиваюсь поскольку это pseudowire устройство всего с двумя интерфейсами работает по принципу «первый пришел первый вышел» — switchfabric congestion отсутствует так как нет этого самого switchfabris и, к слову, mac-learning тоже нет.
есть ли микробуферизация, на какие части делите пакет, как склеиваете обратно. Это вот прямо то, что очень интересно лично мне :-)
По сути дела инкапсулятор это фреймовый буфер (на данный момент он на 4 фрейма размером 2048байт каждый).
Разделение пакета это Вы имеете в виду фрагментацию? Фрагментация в разработке в другой части проекта. Самая сложная чась — склейка фрагментированных фрагментов. Демонстрация принципа алгоритма склейки фрагментов в железе без участия софта здесь.
К вопросу на счет внутреннего устройства на сайте есть раздел «documentation» там есть документация и исходный Verilog. Боюсь что лучше чем там написано я сейчас не смогу объяснить.
Фрагментация — это термин L3+, я про внутреннее хранение и обработку фреймов.
Я так понял, вы просто складываете фрейм целиком.
(Кольцевой) буфер на 2-3 фрейма даст вам лучшую производительность — маркировка и обработка очереди у вас уже, судя по презентации, в каком-то виде есть.
Или соль в том, что вы декодируете заголовок входящего потока на лету, помещая фрейм в буфер с пред-созданным заголовком (mpls, GRE, IPIP)?
После просмотра видео очередной вопрос на перфоманс: вы измеряли внесённую задержку с подходом «положи весь фрейм в буфер, обменяйся сигналами с блоками приёма и обработки, дождись обработки фрейма»?
Задержка обработки в некотором роде связана с глубиной буферизации на входе. Какие ресурсы по памяти предоставляет вам FPGA? Будете ли вы использовать внешнюю память, если-когда памяти на чипе вам не хватит?
Верилог я не пойму :) В любом случае, верилог — это реализация концепции, мне интереснее сама концепция.
Я так понял, вы просто складываете фрейм целиком.
(Кольцевой) буфер на 2-3 фрейма даст вам лучшую производительность — маркировка и обработка очереди у вас уже, судя по презентации, в каком-то виде есть.
Или соль в том, что вы декодируете заголовок входящего потока на лету, помещая фрейм в буфер с пред-созданным заголовком (mpls, GRE, IPIP)?
После просмотра видео очередной вопрос на перфоманс: вы измеряли внесённую задержку с подходом «положи весь фрейм в буфер, обменяйся сигналами с блоками приёма и обработки, дождись обработки фрейма»?
Задержка обработки в некотором роде связана с глубиной буферизации на входе. Какие ресурсы по памяти предоставляет вам 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.
Скажите, вы просто хотите дешево терминировать MPLS? Или проект в целом больше учебный, чем продакшен?
Уже спрашивали выше, но считаю нужным продублировать: 10Гбит/с — это очень, очень, очень мало для того, чтобы возиться с кастомным FPGA. Как вы обосновываете экономическую сторону? (если, опять же, проект преследует не ислючительно учебные цели)
Спасибо. В любом случае, дело вы делаете интересное.
Уже спрашивали выше, но считаю нужным продублировать: 10Гбит/с — это очень, очень, очень мало для того, чтобы возиться с кастомным FPGA. Как вы обосновываете экономическую сторону? (если, опять же, проект преследует не ислючительно учебные цели)
Спасибо. В любом случае, дело вы делаете интересное.
Академическая составляющая проекта чрезвычайно важна!
Ну ведь не имея 1гигабит нельзя получить 10гигабит так же как не имея 10гигабит нельзя получить 40 или 100.
Тем не менее переход на более высокую скорость требует гораздо меньшего количества инженер-часов если а) архитектура устройства определена и отработана, б) блоки и протоколы верификации имеются в наличии, в) накоплен опыт разработки подобных систем.
Ну ведь не имея 1гигабит нельзя получить 10гигабит так же как не имея 10гигабит нельзя получить 40 или 100.
Тем не менее переход на более высокую скорость требует гораздо меньшего количества инженер-часов если а) архитектура устройства определена и отработана, б) блоки и протоколы верификации имеются в наличии, в) накоплен опыт разработки подобных систем.
На более высокой скорости у вас будет другая архитектура в силу разных ньюансов. Вы правы, не _абсолютно_ всё придется переделывать. Но и простой сменой трансивера+serdes вы не обойдётесь.
Поэтому я и спросил, какая цель проекта. В опенсорсе как таковом уже есть baremetal коммутаторы (например, bm-switch.com). Причина терминации на оконечке мне пока из ваших объяснений не ясна (спросите знакомого сетевого инженера, что он думает про «отдать периметр сигнализации и/или транспорта другим людям»).
Поэтому я и спросил, какая цель проекта. В опенсорсе как таковом уже есть baremetal коммутаторы (например, bm-switch.com). Причина терминации на оконечке мне пока из ваших объяснений не ясна (спросите знакомого сетевого инженера, что он думает про «отдать периметр сигнализации и/или транспорта другим людям»).
В опенсорсе как таковом уже есть baremetal коммутаторы (например, bm-switch.com).
Но ведь сами внутренности коммутирующего ASICа закрыты, правильно?
Под опенсорс-ом здесь понимается то что система комманд программирования чипа открыта но не сами «внутренности» чипа.
Если я не прав дайте ссылку на RTL ASICa плиз, я как вижу там используется StrataXGS Tomahawk от BroadCom.
Я не занимаюсь непосредственно разработкой на броадкоме, предметно ответить по чипу не смогу.
Знаю только о существовании Broadcom SDK. Внутренности чипа открыты настолько, насколько это нужно для управления чипом. Увы, даже если бы я что-то знал непосредственно — там везде NDA.
Вы смотрели в сторону P4 (https://p4.org/)?
(извините, я продолжаю не понимать, какая цель проекта, поэтому, возможно, задаю нерелевантные вопросы)
Знаю только о существовании Broadcom SDK. Внутренности чипа открыты настолько, насколько это нужно для управления чипом. Увы, даже если бы я что-то знал непосредственно — там везде NDA.
Вы смотрели в сторону P4 (https://p4.org/)?
(извините, я продолжаю не понимать, какая цель проекта, поэтому, возможно, задаю нерелевантные вопросы)
На более высокой скорости у вас будет другая архитектура в силу разных ньюансов. Вы правы, не _абсолютно_ всё придется переделывать. Но и простой сменой трансивера+serdes вы не обойдётесь.
Правильно, существуют два пути повышения скорости:
Первый увеличение разрядности шины, второй повышение тактовой частоты устройства.
Для того что бы получить 10гигабит line-rate на FPGA мы должны реализовать инкапсулятор на 64-х разрядной шине (которая будет обрабатывать восемь байт за такт вместо одно как на гигабите) и запустив нашу плату на частоте 156.25 МГц получаем десять гигабит.
То есть переход от одного гигабита на десять это фактически смена архитектуры но мы все же находимся в зоне комфорта «жирной» FPGA такой как Cyclone 10GX.
Переход от десяти гигабит на более высокие скорости это уже увеличение тактовой частоты (так как шина уже 64бита куда больше?).
FPGA не может работать на очень высоких тактовых частотах следовательно выход один — берем схемы из репозитория и выпекаем по ним ASIC. ASIC в отличие от FPGA модно запустить на гигагерцовых частотах получив на нем 40-100 гигабит line-rate скорость.
Больше 64-битной шины, например, 512-битная :)
Денис приветствую,
Для простоты перехода от гигабита на десять можно договориться что L3 заголовок всегда кратный 8 байтам (64битам) что бы избежать misalignment между заголовком и телом пакета при их склеивании на выходе мультиплексором.
В этом случает потребуется 8-to-64bit gearbox между восьмибитным выходом генератора заголовка и 64 битным выходящим мультиплексором. Генератор заголовков все равно останется восьмибитныйм, поэтому пока отправляется тело предыдущего пакета одновременно с этим уже идет генерация следующего заголовка и его упаковка в 64битный формат для конечной отправки.
При дальнейшем расширении шины я боюсь что восьмибитный генератор заголовков не будет успевать их генерировать и упаковывать в 64бита (со скоростью байт за такт) пока отправляется предыдущий пакет со скоростью 64 байта за такт то есть выходная скорость будет падать так как слишком большая разница между компонентами.
В коммутаторах такой проблемы нет так как они не меняют сам фрейм то есть им все равно какая шина (хоть 512), они одинаковыми порциями загребают такими же порциями и выбрасывают на выходе.
Для простоты перехода от гигабита на десять можно договориться что L3 заголовок всегда кратный 8 байтам (64битам) что бы избежать misalignment между заголовком и телом пакета при их склеивании на выходе мультиплексором.
В этом случает потребуется 8-to-64bit gearbox между восьмибитным выходом генератора заголовка и 64 битным выходящим мультиплексором. Генератор заголовков все равно останется восьмибитныйм, поэтому пока отправляется тело предыдущего пакета одновременно с этим уже идет генерация следующего заголовка и его упаковка в 64битный формат для конечной отправки.
При дальнейшем расширении шины я боюсь что восьмибитный генератор заголовков не будет успевать их генерировать и упаковывать в 64бита (со скоростью байт за такт) пока отправляется предыдущий пакет со скоростью 64 байта за такт то есть выходная скорость будет падать так как слишком большая разница между компонентами.
В коммутаторах такой проблемы нет так как они не меняют сам фрейм то есть им все равно какая шина (хоть 512), они одинаковыми порциями загребают такими же порциями и выбрасывают на выходе.
Конечно, Вы правы — переход на более широкую шину может привести к значительному усложнению/переделке дизайна.
Просто в сообщении выше Вы написали:
И как вывод:
А это не совсем верно (точнее, совсем не верно) — топовые FPGA позволяют получить поддержку 40G/100G. Для этого придётся использовать шины шириной порядка 256/512 бит и частоты порядка 312.5 МГц.
Конечно, такая разработка:
Но, как говорится, C'est la vie.
Если хочется поддерживать на FPGA большие скорости, придётся прилагать большие усилия.
Просто в сообщении выше Вы написали:
Переход от десяти гигабит на более высокие скорости это уже увеличение тактовой частоты (так как шина уже 64бита куда больше?).
И как вывод:
FPGA не может работать на очень высоких тактовых частотах следовательно выход один — берем схемы из репозитория и выпекаем по ним ASIC
А это не совсем верно (точнее, совсем не верно) — топовые FPGA позволяют получить поддержку 40G/100G. Для этого придётся использовать шины шириной порядка 256/512 бит и частоты порядка 312.5 МГц.
Конечно, такая разработка:
- Много сложнее и дольше, чем для 1G/10G
- Может потребовать написания с нуля большого числа модулей. Так как модули для 1G/10G переиспользовать не получится
Но, как говорится, C'est la vie.
Если хочется поддерживать на FPGA большие скорости, придётся прилагать большие усилия.
Какой порядок PPS вы планируете получите сейчас, на 10Gbps?
Что планируете получить на 100Gbps путем описанного масштабирования?
Для пакетов размером 64B-128B, например.
Что планируете получить на 100Gbps путем описанного масштабирования?
Для пакетов размером 64B-128B, например.
Планируем получить 10Gb ethernet line-rate speed как в ethernet коммутаторах.
Размер пакетов тут особой роли не играет (ну почти не играет у каждого фрейма ведь есть — избыточная преамбула ethernet, inter-frame-interval, CRCs).
Размер пакетов тут особой роли не играет (ну почти не играет у каждого фрейма ведь есть — избыточная преамбула ethernet, inter-frame-interval, CRCs).
Если просто взять и поделить, это 19.5 млн пакетов в секунду. Которые должны как минимум быть просто последовательно обработаны (в вашем случае с 2 портами этого достаточно). У вас устройство работает только в симплексном режиме? Количество портов не превысит два?
Для какого размера таблицы правил инкапсуляции число 19.5 млн еще будет выполняться?
Для какого размера таблицы правил инкапсуляции число 19.5 млн еще будет выполняться?
так как шина уже 64бита куда больше?
Зачем сковывать себя типовыми разрядностями? Это же FPGA — там можно всё, что в чип лезет.
Кстати, сейчас типовая частота для расслабленного дизайна в FPGA уже не 150 а 300 Мгц.
etherblade в вашей модели, как я понял, 10G инкапсулируется в те же самые 10G и объем трафика на выходе должен увеличиться. Получается в предельных режимах возможна потеря пакетов?
Верно все как на коммутаторах — 100% загрузка буфера инкапсулятора вызовет buffer-overflow на входящем FIFO и данные фреймы будут промаркированы как «битые» и отброшены инкапсулятором.
Можно сделать инкапсулятор с более глубокой буфферизацией (на 32 ethernet фрейма вместо четырех) для лучшей обработки burst-траффика.
Можно сделать инкапсулятор с более глубокой буфферизацией (на 32 ethernet фрейма вместо четырех) для лучшей обработки burst-траффика.
Это интересно, а не пробовали замерять деградацию производительности для таких случаев (переполнения fifo)? Особенно интересно как поведёт себя девайс в случае нагрузки tcp, какие просадки будут. На уровне ethernet никакого flow control не используете? И если не используете, то по каким соображениям?
Это очень интересно.
Вообще сам процесс синтезирования RTL (читай Verilog/VHDL) и портирования его на FPGA, создание системы на кристалле и тестирования всего этого дела в работе интереснейшее занятие.
Похоже пора создавать форум, выкладывать гайды по портированию и ждать результатов тестов от community. Помню в СССР был журнал радио где выкладывалась схема, которую паяли у себя дома, тестировали и в следующих журналах делились мнениями и необходимыми доработками.
Сегодня есть FPGA так что можно делать чипы не отходя от лаптопа.
Вообще сам процесс синтезирования RTL (читай Verilog/VHDL) и портирования его на FPGA, создание системы на кристалле и тестирования всего этого дела в работе интереснейшее занятие.
Похоже пора создавать форум, выкладывать гайды по портированию и ждать результатов тестов от community. Помню в СССР был журнал радио где выкладывалась схема, которую паяли у себя дома, тестировали и в следующих журналах делились мнениями и необходимыми доработками.
Сегодня есть FPGA так что можно делать чипы не отходя от лаптопа.
Знаете, с синтезом и проектированием под FPGA хорошо знаком) Вопросы задавал не спроста, а с целью обогащения опытом, есть серьезные подозрения (но, конечно, могу и ошибаться) что в вашей реализации будут существенные просадки для tcp и прозрачной ваша реализация не будет. Думал, что вы это уже решили, похоже ещё не добрались.
Почему будут просадки по tcp? Инкапсулятор не будет даже знать что у него там за пакет. Это ведь по сути дела хардварный буфер с некоторой логикой прикрепления заголовков из памяти в зависимости номера VLAN. В инкапсуяторе нет TCP/IP стека, тем не менее инкапсулировать ethernet в IPv4/IPv6 он умеет если в памяти адресуемой данным номером влана прописан заголовок формата IPv4/IPv6.
Вы пишете, что теряются пакеты когда переполняется fifo, это будет вызывать повторные пересылки у tcp (хоть инкапсулятор не знает о типе нагрузки, о потерях пакетов узнают клиент и сервер tcp и начнут реагировать), будет уменьшаться congestion window у отправителя да и просто больше подтверждений будет сыпаться вместо полезного трафика, т.е. пойдет деградация. Спору нет, если нагрузка слабая или не tcp, никто и не заметит, а вот на полную если загрузить с одного клиента tcp, тогда, по-моему, пойдут чудеса.
tcp — саморегулируемый протокол, он начинает разгоняться с нуля и при первых дропах (возникающих в самом узком месте сети я не думаю что 10гигабитный инкапсулятор часто будет таковым являться) начинает «сбрасывать газ».
В любом случае хардварному буферу не интересно какой там пакет. Его заботит только один параметр — номер vlan входящего ethernet фрейма.
В любом случае хардварному буферу не интересно какой там пакет. Его заботит только один параметр — номер vlan входящего ethernet фрейма.
По поводу tcp и саморегулируемости, он не только сбрасывает газ, но может и добавлять его, когда видит такую возможность, в результате могут появляться ощутимые скачки. Суммируя ваш ответ, правильно ли понимаю, что в девайсе никакого управления потоком не реализовывали, даже на ethernet уровне, и такие вещи не планируете?
И ещё вопрос, по ссылке на ваш проект в описании сказано следующее:
Additional features like encryption can be added with zero impact on the system’s performance.. Подскажите, как это измерялось или на чем базируется предположение? Учитывая, что время на зашифрование пакетов существенно разнится в зависимости от размеров пакета, не говоря уже об особенностях алгоритма шифрования, интересно, как вы это планируете реализовать, не ухудшив производительность?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Etherblade.net — opensource проект по созданию инкапсулятора ethernet-трафика на FPGA (часть первая)