Ага, есть, очень много — в этом и проблема) Кстати, они могут работать на в принципе, любой карточке которая поддерживает их базовый фреймворк (e.g. DPDK, snabb). Тут все зависит от того, что мы хотим поднять на нем. В случае TCP — все не просто. TCP очень сложный и «mature» и его реализация в Linux Kernel шибко нетривиальная и весьма хорошо отлажена со временем. Готовые байпас TCP стеки обычно реализуют определенное подмножество TCP, и не на столько хорошо отлажены [ medium.com/@penberg/on-kernel-bypass-networking-and-programmable-packet-processing-799609b06898 ]. Плюс люди обычно спускаются до байпаса, когда хотят получить высокую (и стабильную) производительность при высокой нагрузке. В таких случаях, не всегда удается этого достичь только с байпасом, нужно и стек подкрутить. В общем, на практике, с байпасом больше возни получается. Фактичски, тут нет стандарта [ medium.com/@penberg/on-kernel-bypass-networking-and-programmable-packet-processing-799609b06898 ], есть много разных реализаций со своими упрощениям и багами, и все это не шибко хорошо поддерживается.
Все, понял! Пулинг Completion Queue, видимо, имеется ввиду в статье. Тема неплохо раскрыта тут: arxiv.org/pdf/2002.02563.pdf. Извеняюсь за лишнее беспокойство.
Метод poll может использоваться также и для передачи пакетов.
А как именно работает poll на передачу? На передаче, нужно кидать данные в кольцо, doorbell'ить NIC и тогда он сделает DMA и заберет данные с кольца. Если можно, было бы интересно узнать больше как тут работает пулинг, есть ссылочки, плиз?
Еще с байпасом надо писать/адаптировать/поддерживать свой стек (это, конечно, не RDMA, но все равно дополнительная работа).
Но байпас хорош, когда надо сильно оптимизировать стек, и иногда выше, чем транспорт. Замечательная статья: www.usenix.org/conference/nsdi19/presentation/kalia на тему запуска RPC стека в байпасе, средняя раунд-трип 2.3 us (по сути, пракический потолок по PCIe и ToR сети)! Но опять же, очень очень много вопросов по безопасности. Этот результат они получили через raw драйвер, т.е. даже байпася DPDK, напярмую кидая пакеты на NIC ;)
Смотрите — Питон заведомо менее эффективен, чем С++. И тем не менее, сегодня он прочно захватил «рынок» исследований. Причина — большое количество библиотек и фрейворков, в результате которых у вас наверху может быть Питон-ноутбук, а внизу — GPU, FPGA или любая другая эффективная железка.
Не совсем, Питон захватил свою нишу в высоконагруженных приложениях во многом благодаря его нахождения поверх самой реализации примитивов этих приложений на нативных языках. А в случае FPGA, никакого «нативного» бэкенда с ASIC'ми нет и это надо неизбежно принять: FPGA фундаментально медленнее/менее эффективны, чем ASIC'и.
FPGA хороши для 1) прототипирования ASIC-ов; 2) специальных приложений которые из-за малого тиража не имеет смысла заказывать на фабрике (обработка сигналов или скажем сетевых пакетов) 3) образования.
Но как мне, человеку с малым опытом (опыт исследований в области меньше года пока) видится, из-за возможности быстрой реализации и «software defined hardware», FPGA находят очень много применений в традиционных Computer Science областях:
In-network processing (было озвучено)
Глубокое обучение, пока inference (было озвучено)
Системы хранения дынных. Тут большой выигрыш получается из-за возможности разместить сетевой стек и логику базы данных на одном чипе — очень важно для уменьшения latency. В частности, люди используют FPGA для реализации систем хранения данных Ключ-Значение (Key-value store) и графовых баз данных. Посмотрите на один из форков Microsoft Catapult: www.microsoft.com/en-us/research/project/honeycomb
«Традиционные» алгоритмы баз данных тоже неплохо ускоряются на FPGA
RDMA системы (программируемые NIC уже достаточно давно основаны и на FPGA, в том числе
И вагончик более специализированных применений: биоинформатика, финансовая аналитика (HFT, например), сжатие данных и тд...
И все это сейчас без проблем можно найти на оффлоаде в одном облаке и в примерно одно время. Конечно, если сделать ASIC под каждый пример использования и напичкать ими датацентры, то все будет гораздо круче, чем с FPGA, но это просто не реалистично. А FPGA можно быстро реконфигурировать под текущую нагрузку на центр. Этот аргумент мне в последнее время довелось очень часто слышать.
Что-то похожее пытаются сделать и в рамках проекта TVM в частности ( tvm.ai/about), где стек восстановлен от фронденда (того же самого Keras) и до самого низа. Как я понял, основная новизна этого конкретно проекта — поддержка «высоко»-гетерогенного железа (bare metal, процессоры с кастомным ISA, FPGA и тд.) с уклоном во встраиваемые системы и edge computing. Есть ряд исследовательских групп сформировавшихся вокруг TVM пытающихся прикрутить HLS к TVM как бэкэнд для FPGA. Хороший HLS может сделать парадигму программирование FPGA «ближе» к мировозрению софтварного программиста, и (в идеале) сделать универсальное прототипирование сеток под FPGA так же из коробки, как и под GPU/TPU сейчас.
P.S. Еще FPGA позволяют реализовывать концепцию transparent hardware (и рядом — open-source hardware), что может помочь решить вопросы безопасности и конфиденциальности, что особенно важно если вы оффлоадите свою уникальную модель (да еще и с «деликатными» данными) в облачко на обучение. Но это пока скорее ресерч-ресерч. В общем, FPGA в новом свете современных нагрузок и требований — это реально круто и это направление надо копать ;)
Супер статья, грамотно написана и по делу. Спасибо большое! А из плюсов FPGA я бы еще добавил возможность реализации арифметики произвольной точности, что очень активно используется как в выполнении (после квантования может остаться исключительно целочисленная арифметика низкой точности (до 8 бит и иногда даже меньше), что позволяет синтезировать больше арифметических модулей на FPGA), так и в обучении (пока на стадии исследований, например, arxiv.org/abs/1803.03383).
Доброго времени суток! Помогите разобраться! Есть WiFi роутер и к нему подключены несколько компьютеров. В каком случае они будут входить в один широковещательный домен? Или ни в каком, ведь это же роутер и он работает на 3ем уровне OSI и удаляет все широковещательные пакеты?
Добрый вечер! Спасибо за отличную статью! Я новичек в kernel и меня уже второй день мучает вопрос, который я никак нигде не могу нагуглить. На сколько я понял, отображение файла — это чтение данных из него через адрес в виртуальной памяти, без непосредственной загрузки данных в память (только в кэш, а он маленький совсем). То есть, при попытке считать по адресу замэпленного файла, на самом деле происходит чтение из файла.
Вы писали, что в Линуксовском процессе все so-шки и файл с кодом программы мапятся в память как раз по описанному механизму. Правильно ли я понимаю, что при чтении инструкции из so-шной библиотеки или кода, каждый (ну или почти каждый) раз идет обращение к файлу (через отображение), то есть к ПЗУ, то есть к жесткому диску, то есть ОЧЕНЬ МЕДЛЕНО. Как-то странно получается, ведь оперативная память на то и сделана, чтобы уменьшить колличество чтений из ПЗУ и ускорить выполнение… Или эта so-шка в начале вся грузится в память (хотя смысл тогда в отображении)… не понимаю… Буду очень признателен за ответ на вопрос)
Конечно, и за короткий срок одному человеку выполнить это тяжеловато, но если разделить задачи (интеграция ядра, софт, периферия), то проект вполне имеет право на жизнь.
Интеграция процессорного ядра в ПЛИС сейчас уже достаточно тривиальная задача. Во многоих проектах DSP так и делается. Кроме того, девайс скорее всего будет выполнять специализированную задачу и софт для Вашего ядра врядли будет обновляться каждый месяц и вряд ли будет шибко сложным.
Не за что! К Вашему вопросу: из спецификации: 25 MB/sec = 50 MHz клока. То есть 10 MB/sec = 20 MHz клока. Stm32f4 обеспечит до 25 MHz клока без проблем, а копирование данных с одной карточке на другую можно реализовать через DMA, то есть без вмешательства ЦП. Да и поддержку файловую системы проще на МК реализовать. На ПЛИСе тоже можно, но это будет жестче, хотя мб есть готовые модули… но на скорости 10 MB/sec в этом нет особого смысла, ибо в мк SDIO, как правило, тоже аппаратный.
Еще с байпасом надо писать/адаптировать/поддерживать свой стек (это, конечно, не RDMA, но все равно дополнительная работа).
Но байпас хорош, когда надо сильно оптимизировать стек, и иногда выше, чем транспорт. Замечательная статья: www.usenix.org/conference/nsdi19/presentation/kalia на тему запуска RPC стека в байпасе, средняя раунд-трип 2.3 us (по сути, пракический потолок по PCIe и ToR сети)! Но опять же, очень очень много вопросов по безопасности. Этот результат они получили через raw драйвер, т.е. даже байпася DPDK, напярмую кидая пакеты на NIC ;)
Не совсем, Питон захватил свою нишу в высоконагруженных приложениях во многом благодаря его нахождения поверх самой реализации примитивов этих приложений на нативных языках. А в случае FPGA, никакого «нативного» бэкенда с ASIC'ми нет и это надо неизбежно принять: FPGA фундаментально медленнее/менее эффективны, чем ASIC'и.
Но как мне, человеку с малым опытом (опыт исследований в области меньше года пока) видится, из-за возможности быстрой реализации и «software defined hardware», FPGA находят очень много применений в традиционных Computer Science областях:
И все это сейчас без проблем можно найти на оффлоаде в одном облаке и в примерно одно время. Конечно, если сделать ASIC под каждый пример использования и напичкать ими датацентры, то все будет гораздо круче, чем с FPGA, но это просто не реалистично. А FPGA можно быстро реконфигурировать под текущую нагрузку на центр. Этот аргумент мне в последнее время довелось очень часто слышать.
P.S. Еще FPGA позволяют реализовывать концепцию transparent hardware (и рядом — open-source hardware), что может помочь решить вопросы безопасности и конфиденциальности, что особенно важно если вы оффлоадите свою уникальную модель (да еще и с «деликатными» данными) в облачко на обучение. Но это пока скорее ресерч-ресерч. В общем, FPGA в новом свете современных нагрузок и требований — это реально круто и это направление надо копать ;)
Вы писали, что в Линуксовском процессе все so-шки и файл с кодом программы мапятся в память как раз по описанному механизму. Правильно ли я понимаю, что при чтении инструкции из so-шной библиотеки или кода, каждый (ну или почти каждый) раз идет обращение к файлу (через отображение), то есть к ПЗУ, то есть к жесткому диску, то есть ОЧЕНЬ МЕДЛЕНО. Как-то странно получается, ведь оперативная память на то и сделана, чтобы уменьшить колличество чтений из ПЗУ и ускорить выполнение… Или эта so-шка в начале вся грузится в память (хотя смысл тогда в отображении)… не понимаю… Буду очень признателен за ответ на вопрос)