Принять и ПАРАЛЛЕЛЬНО распарсить поток 10Гбит/с. Как решаются такие задачи? Опции

[Студент заборстр...]

Поясню.
По езернету принимаем данные об состоянии 1000 ОДИНАКОВЫХ распределенных устройств на скорости 10 Гбит/с по оптоволокну, обрабатываем и формируем "ответку". Которую тоже передаем по оптоволоку на 10Гбит/с
Т.к. устройства одинаковые, то алгоритм работы и логика обработки дампа от каждого устройства одинакова.

Отсюда возникает желание обрабатывать все дампы ПАРАЛЛЕЛЬНО.

Отсюда в голове появляется слово "ПЛИС".

Но возникает вопрос "Как?"

Я вижу это так. Есть память. Допустим 1 Мегабайт.
В эту память пишем принятые дампы из принятых пакетов, из неё же грузим данные в пакеты.
Тут пока ничего не обычного.

Необычное начинается тут:
Память должна быть разбита на 1000 сегментов и доступ к каждому сегменту должен быть возможен НЕЗАВИСИМО от других
ПЛИСина должна читать из 1000 дампов/сегментов ОДНОВРЕМЕННО и обрабатывать 1000 потоков параллельно и потом формированные данные 1000 потоков параллельно: каждый узел обработки пишет, читает собрабатывает свой дамп.

Пруфит? Увеличение скорости реакции в 1000 раз по сравнению с последовательной обработкой на MCU


Я объяснил несколько шероховато, поскольку не специалист по ПЛИС.

Меня интересует это реализуемо на ПЛИС.
И есть ли такая память, которая позволяет использовать её одновременно как единый блок и как совокупность дампов с независимым доступом к каждому дампу?

Т.е. при сериализации/десериализации память используется как неделимый блок.
А при обработке данных в памяти она должна использоваться ПЛИСиной как набор из 1000 независимых дампов с независимым доступом.

Такое есть в природе?

Или описанные мной задачи решаются как-то иначе?

Просто обычный MCU даже i7 не успеет обработать поток 10Гбит/сек (а есть мысли сделать даже 100Гб/с).
Нужно как-то распараллеливать обработку

А как?

Сообщение отредактировал Студент заборстроительного - Dec 23 2017, 11:07

[krux]

с таким подходом - НЕТ.

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

2 ТС
умеете работать с x86 - берите DPDK в руки. это если нужен практический результат.
если практический результат пофиг и вы пишете кандидатскую, ничего не зная про предметную область плис - вас на защите как катком раскатают.

Нужно парсить именно в 1000 потоков и данные поступающие со скоростью 10 Гб/с.

поясняю:
парсинг в плис - это не 1000 раз сравнить один байт с "чем-то".
для понимания в чем эффективность ПЛИС - нужно окунуться с головой в поиск по бинарному дереву, когда речь идёт не про сравнение строк, байтов ли чего ещё, а про сравнение СЛЕДУЮЩЕГО ПРИХОДЯЩЕГО БИТА. блин.
нового решения по поиску исходя из сравнения очередного бита.
за счет этого собственно производительность и достигается.

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


а сейчас я вижу как производится попытка впихнуть некое "распарсивание" без понимания последствий.
таким образом, налицо все попытки "скрыть это дерьмо" за какой-нибудь ПЛИС, которая будет никому не понятна, кроме тебя.

[Студент заборстр...]

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

Ну а я то причем?
Не я же Вам ТЗ писал.
Да и в этой теме не стоит задача проработать ТЗ вплоть до мельчайших деталей реализации.
Здесь обсуждается сама концепция, архитектура. Возможно ли её реализовать на одной ПЛИС или нет.

Ну если Вам трудно мыслить абстрактно, то давайте к конкретике (пример вымышленный /но все же он передает то, чего в реале я хотел бы получить/, поэтому обсуждение "для чего оно нужно?" давайте оставим "за кадром").

Допустим каждый из тысячи узел ПЛИС просто каждые 10 мкс считывает байт за байтом инфу из своего дампа (64 байта) памяти 10G приемника, делает операцию XOR с некоей константой и записывает в память 10G передатчика.
Приемник и передатчик никак не синхронизируются между собой и с узлами. Узлы в ПЛИС также работают совершенно независимо от других узлов, 10G-приемника и 10G-передатчика
Каждый просто ТУПО делает свою работу не взирая на то, в каком состоянии находятся данные.

Теперь. Когда есть конкретика Вы можете оценить сложность реализации такого проекта?

Если сильно утрировать, вся система с 1000 устройств на одной стороне 10G эзернет кабеля и 1000 узлов ПЛИС на другой должна работать также, как 1000 удаленных устройств подключенных 1000 кабелями каждый к своему микроконтроллеру.

Т.е. вся затея служит для того, чтобы не "тащить" 1000 кабелей и не использовать 1000 микроконтроллеров, а обойтись одним кабелем, ПЛИСиной и 10G приемопередатчиками на обоих сторонах кабеля

Сообщение отредактировал Студент заборстроительного - Jan 3 2018, 12:33

[Inanity]

Допустим каждый из тысячи узел ПЛИС просто каждые 10 мкс считывает байт за байтом инфу из своего дампа (64 байта) памяти 10G приемника, делает операцию XOR с некоей константой и записывает в память 10G передатчика.

Такая задача имеет решение. Но для её решения не нужно 1000 узлов. Ядро 10Gb ethernet выдаёт обычно 64 бита на частоте ~156Мгц. Далее XOR с константой, запись в промежуточный регистр и вывод на ядро передатчика в том же виде (64 бит ~156Мгц). Глубина конвейера - 1 такт, частота работы ~156Мгц.

Просто немного смешно. Это такая пушка по воробьям))

Сообщение отредактировал Inanity - Jan 3 2018, 13:34

[Студент заборстр...]

Такая задача имеет решение. Но для её решения не нужно 1000 узлов.
...
Просто немного смешно. Это такая пушка по воробьям))

Вот опять "снова здорова".
Да плевать, что "из пушки по воробьям", плевать, что можно НЕ решать такую задачу.
Плевать что с помощью разных хаков можно свести задачу к меньшей размерности.
ПЛЕВАТЬ.
Мне нужно решить задачу именно так, как я указал в заголовке. Чтобы "обкатать" саму архитектуру

И потом, я же сказал, что пример с "ХОR" вымышленный.
В реальности же каждый узел ПЛИС будет целым микроконтроллером и обработка дампа будет описываться достаточно большой прогой на Си.

Но с точки зрения идеологии построения системы, с точки зрения архитектуры НЕ ВАЖНО, будет ли "программа обработки" просто XOR-ом или большой программой.

Это понятно?

Я сначала думал для обеспечения "параллелизма" поставить 1000 маленьких микроконтроллеров.
Но потом вспомнил, что можно создать эти самые микроконтроллеры внутри одной ПЛИС

Теперь понятно "откуда ноги растут"?

Сообщение отредактировал Студент заборстроительного - Jan 3 2018, 17:41

[Александр77]

Теперь понятно "откуда ноги растут"?

Понятно что ноги пустились вскачь!
Еще на первой странице Вам сказали - более или менее реальную задачу надо обсчитать от начала до конца: что с какой скоростью откуда загружается, что как потом представляется внутри ПЛИС передатчика, как потом восстанавливать данные в ПЛИС приемнике, сколько на это будет затрачено времени, ресурсов и т.д. И в итоге, что будет в выходном потоке куда и как идти.
Теперь у Вас появились микроконтроллеры, которые Вы хотите запихнуть в ПЛИС или заменить микроконтроллеры узлами ПЛИС, не суть важно.
Нет, так можно сварить только одну кашу - в голове.
Разгребайте авгиевы конюшни, рисуйте структуру своей гипотетической системы, расставляйте времена, порядок представления данных, желаемый вид в оконечном устройстве и тогда лишь преступайте к вопросам о "влезет не влезет?".