Comments 21
Насколько я помню со слов наших FPGA-разработчиков, ускорители шифрования и дешифрования в FPGA реализованы в виде независимых друг от друга клубков проводов. Поэтому со стороны FPGA никаких препятствий для одновременного шифрования и дешифрования быть не должно. Читая исходники CryptoAPI ядра я тоже не нашёл никаких помех для этого.
Но в драйвере есть несоклько полей структуры, которые используются и шифрующей и дешифрующей функциями. Похоже, что прямо сейчас только это помешает запустить параллельно шифрование и дешифрование. Такое негибкое решение мы реализовали на самых ранних этапах разработки, так как тестировали шифрование и дешифрование только по очереди. Давно собирались переписать, но руки не дошли.
Я, наверное, всё же доберусь до починки этого в ближайшие пару недель. Ждите тогда новые графики.
Как всегда очень интеренесо!
PS. Можете как нибудь прокоментировать вот этот вопрос #comment_10195914
Читатель, который посмотрит не только на форму линий, но и на конкретные числовые значения, конечно, удивится: почему дешифрование стабилизируется на 250 Мбит/с, а шифрование — на 400 Мбит/с? На самом деле драйвер тут совершенно ни при чём, так происходит потому, что в FPGA, несмотря на зеркальный интерфейс, процедуры шифрования и дешифрования реализованы по-разному.
Это и без комментария понятно, что по-разному, и ничего не объясняет.
Идея интересная, но, боюсь, нежизнеспособная.
Я нашёл свои старые измерения, того, на что тратится процессорное время при работе iperf через openvpn с софтовой релизацией AES-128-CBC: flame graph. О том, как интерпретировать flame graph, читайте http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html .
Эта (кликабельная) картинка, была построена по perf.data, полученному командой perf record -a -g -- iperf -c some.host.
По ней можно понять, что на шифрование уходит меньше 20% процессорного времени. Кучу времени процессор провёл в системных вызовах (send, recv, poll) и в функции sha1_block_data_order. Кажется, проще перейти на Blowfish, чем AES ускорять :) .
К распараллеливанию на многоядерном процессоре тоже есть вопросы. Я не знаю, умеют ли libcrypto, libssl или ещё какие-то криграфические библиотеки распараллеливаться из коробки.
во-2х, 20% у aes_encrypt и 17% у sha1_block — даже если их просто сколлапсить, это уже 17% экономия. а если еще и оба упадут на fpga, так что в итоге суммарно в 4 раза быстрее чем на сру — то вместо 37% получам 5% — что даёт ускорение на треть.
нет, распараллеливать из коробки они не умеют.
В будущем мы собираемся ускорить именно OpenVPN на EthondУскорьте, пожалуйста. Сейчас действительно основное время проводится в recv, send и poll. Это из-за того, что в TAP-устройство нельзя писать или читать несколько пакетов одним системным вызовом, и нет никакого механизма offloading, кроме IFF_VNET_HDR, который не особо полезен. Модули, построенные на TAP, реализуют свой протокол поверх TAP, разбивая несколько фреймов в один большой и собирая его на другом конце. Так делает, если не ошибаюсь, macvtap, vxlan и virtio.
Проверить эту теорию и ускорить OpenVPN достаточно просто — задайте интерфейсу большой MTU в серверном и клиентском конфигурационном файле:
mssfix 0
tun-mtu 18000
Если вы добавите в TAP возможность читать и писать несколько пакетов за один вызов, это будет очень полезно не только OpenVPN, но и куче других проектов. Сейчас, со стандартным MTU, TAP развивает максимальную скорость около гигабита в секунду на десктопных процессорах, захлебываясь в переключениях контекста.
вопрос — отчего графики перфоманса хардверной реализации такие рваные?
У драйвера между моментами, когда он отдавал в FPGA адреса буфферов с данными, было время спать. Особенно это заметно при больших объёмах данных. Это значит, что со своей задачей он справлялся и у FPGA всегда были данные для обработки. Я пока не уверен, думаю, нам стоит дождаться ответа авторов прошивки FPGA, чтобы можно было ответить на вопрос о том, чем сейчас ограничивается скорость.
Слышал краем уха, что впихивание ширины во всё доступное (кратное блоку) давало выигрыш по энергоэффективности (ну и кратное ускорение, разумеется).
Сколькитактное ядро, к слову, получили? Может, оттуда разница в пиковой производительности?
Как мы на FPGA AES ускоряли: разработка драйвера