Для зависимых типов нужна будет проверка тотальности. И с ней будет трудно писать программы. Именно прикладные программы. Идрис ставил себе целью совместить эти две вещи. Посмотрите, что получилось. Может быть, вам он нужен, а не Хаскель.
У драйвера между моментами, когда он отдавал в FPGA адреса буфферов с данными, было время спать. Особенно это заметно при больших объёмах данных. Это значит, что со своей задачей он справлялся и у FPGA всегда были данные для обработки. Я пока не уверен, думаю, нам стоит дождаться ответа авторов прошивки FPGA, чтобы можно было ответить на вопрос о том, чем сейчас ограничивается скорость.
Эта (кликабельная) картинка, была построена по perf.data, полученному командой perf record -a -g -- iperf -c some.host.
По ней можно понять, что на шифрование уходит меньше 20% процессорного времени. Кучу времени процессор провёл в системных вызовах (send, recv, poll) и в функции sha1_block_data_order. Кажется, проще перейти на Blowfish, чем AES ускорять :) .
К распараллеливанию на многоядерном процессоре тоже есть вопросы. Я не знаю, умеют ли libcrypto, libssl или ещё какие-то криграфические библиотеки распараллеливаться из коробки.
Насколько я помню со слов наших FPGA-разработчиков, ускорители шифрования и дешифрования в FPGA реализованы в виде независимых друг от друга клубков проводов. Поэтому со стороны FPGA никаких препятствий для одновременного шифрования и дешифрования быть не должно. Читая исходники CryptoAPI ядра я тоже не нашёл никаких помех для этого.
Но в драйвере есть несоклько полей структуры, которые используются и шифрующей и дешифрующей функциями. Похоже, что прямо сейчас только это помешает запустить параллельно шифрование и дешифрование. Такое негибкое решение мы реализовали на самых ранних этапах разработки, так как тестировали шифрование и дешифрование только по очереди. Давно собирались переписать, но руки не дошли.
Я, наверное, всё же доберусь до починки этого в ближайшие пару недель. Ждите тогда новые графики.
1.4 Bytestream Timestamps
The SO_TIMESTAMPING interface supports timestamping of bytes in a
bytestream. Each request is interpreted as a request for when the
entire contents of the buffer has passed a timestamping point. That
is, for streams option SOF_TIMESTAMPING_TX_SOFTWARE will record
when all bytes have reached the device driver, regardless of how
many packets the data has been converted into.
Они обещают сообщить пользовательскому приложению момент, когда последний байт данных пройдет "timestamping point". Хотя они упоминают явно только отправку пакета, полагаю что это применимо и к приему.
Лучшая документация по ядру — его исходники. Если разберетесь, обязательно расскажите нам :).
Да, есть и такой способ. Можно после получения (recv) пакета из сокета дернуть ioctlSIOCGSTAMP или SIOCGSTAMPNS и получить время получения ядром этого пакета. Последний ioctl возвращает struct timespec допускающую точность до наносекунд, в отличие от первого, который возвращает struct timeval с микросекундами.
Полученное таким образов время ничем не будет отличаться времени полученного через SO_TIMESTAMPING с установленным флагом SOF_TIMESTAMPING_RX_SOFTWARE.
Но есть еще один способ получить то же самое, сделав на один системный вызов меньше. Опция сокета SO_TIMESTAMP (не путать с SO_TIMESTAMPING) включает доставку временных меток в контрольном сообщении. Временные метки те же самые, что и в SIOCGSTAMP.
Codepast people – programmers’ sunset
I thought direct speech uses different quotation rules in English. This text seems to be written in Russian punctuation style.
Нет, в Haskell неудобно обрабатывать ошибки (если не пользоваться эффектами)
Для зависимых типов нужна будет проверка тотальности. И с ней будет трудно писать программы. Именно прикладные программы. Идрис ставил себе целью совместить эти две вещи. Посмотрите, что получилось. Может быть, вам он нужен, а не Хаскель.
Нет, в Haskell неудобно обрабатывать ошибки (если не пользоваться эффектами)
Хорошая, вдумчивая статья (не всю пока прочитал — в процессе). Давно не читал на Хабре чего-то, что мне бы понравилось. Спасибо!
Summ3r 0f h4ck: стажировка Digital Security 2019
Вы платите стажёрам зарплату или степендию?
Как мы на FPGA AES ускоряли: разработка драйвера
У драйвера между моментами, когда он отдавал в FPGA адреса буфферов с данными, было время спать. Особенно это заметно при больших объёмах данных. Это значит, что со своей задачей он справлялся и у FPGA всегда были данные для обработки. Я пока не уверен, думаю, нам стоит дождаться ответа авторов прошивки FPGA, чтобы можно было ответить на вопрос о том, чем сейчас ограничивается скорость.
Как мы на FPGA AES ускоряли: разработка драйвера
Идея интересная, но, боюсь, нежизнеспособная.
Я нашёл свои старые измерения, того, на что тратится процессорное время при работе
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или ещё какие-то криграфические библиотеки распараллеливаться из коробки.Как мы на FPGA AES ускоряли: разработка драйвера
Насколько я помню со слов наших FPGA-разработчиков, ускорители шифрования и дешифрования в FPGA реализованы в виде независимых друг от друга клубков проводов. Поэтому со стороны FPGA никаких препятствий для одновременного шифрования и дешифрования быть не должно. Читая исходники CryptoAPI ядра я тоже не нашёл никаких помех для этого.
Но в драйвере есть несоклько полей структуры, которые используются и шифрующей и дешифрующей функциями. Похоже, что прямо сейчас только это помешает запустить параллельно шифрование и дешифрование. Такое негибкое решение мы реализовали на самых ранних этапах разработки, так как тестировали шифрование и дешифрование только по очереди. Давно собирались переписать, но руки не дошли.
Я, наверное, всё же доберусь до починки этого в ближайшие пару недель. Ждите тогда новые графики.
SO_TIMESTAMPING в картинках. Прием пакета
Documentation/networking/timestamping.txt об этом говорит следующее:
Они обещают сообщить пользовательскому приложению момент, когда последний байт данных пройдет "timestamping point". Хотя они упоминают явно только отправку пакета, полагаю что это применимо и к приему.
Лучшая документация по ядру — его исходники. Если разберетесь, обязательно расскажите нам :).
SO_TIMESTAMPING в картинках. Прием пакета
Да, есть и такой способ. Можно после получения (
recv) пакета из сокета дернутьioctlSIOCGSTAMPилиSIOCGSTAMPNSи получить время получения ядром этого пакета. Последнийioctlвозвращаетstruct timespecдопускающую точность до наносекунд, в отличие от первого, который возвращаетstruct timevalс микросекундами.Полученное таким образов время ничем не будет отличаться времени полученного через
SO_TIMESTAMPINGс установленным флагомSOF_TIMESTAMPING_RX_SOFTWARE.Но есть еще один способ получить то же самое, сделав на один системный вызов меньше. Опция сокета
SO_TIMESTAMP(не путать сSO_TIMESTAMPING) включает доставку временных меток в контрольном сообщении. Временные метки те же самые, что и вSIOCGSTAMP.См. Documentation/networking/timestamping.txt