Для зависимых типов нужна будет проверка тотальности. И с ней будет трудно писать программы. Именно прикладные программы. Идрис ставил себе целью совместить эти две вещи. Посмотрите, что получилось. Может быть, вам он нужен, а не Хаскель.
У драйвера между моментами, когда он отдавал в 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.
I thought direct speech uses different quotation rules in English. This text seems to be written in Russian punctuation style.
Для зависимых типов нужна будет проверка тотальности. И с ней будет трудно писать программы. Именно прикладные программы. Идрис ставил себе целью совместить эти две вещи. Посмотрите, что получилось. Может быть, вам он нужен, а не Хаскель.
Хорошая, вдумчивая статья (не всю пока прочитал — в процессе). Давно не читал на Хабре чего-то, что мне бы понравилось. Спасибо!
Вы платите стажёрам зарплату или степендию?
У драйвера между моментами, когда он отдавал в FPGA адреса буфферов с данными, было время спать. Особенно это заметно при больших объёмах данных. Это значит, что со своей задачей он справлялся и у FPGA всегда были данные для обработки. Я пока не уверен, думаю, нам стоит дождаться ответа авторов прошивки 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или ещё какие-то криграфические библиотеки распараллеливаться из коробки.Насколько я помню со слов наших FPGA-разработчиков, ускорители шифрования и дешифрования в FPGA реализованы в виде независимых друг от друга клубков проводов. Поэтому со стороны FPGA никаких препятствий для одновременного шифрования и дешифрования быть не должно. Читая исходники CryptoAPI ядра я тоже не нашёл никаких помех для этого.
Но в драйвере есть несоклько полей структуры, которые используются и шифрующей и дешифрующей функциями. Похоже, что прямо сейчас только это помешает запустить параллельно шифрование и дешифрование. Такое негибкое решение мы реализовали на самых ранних этапах разработки, так как тестировали шифрование и дешифрование только по очереди. Давно собирались переписать, но руки не дошли.
Я, наверное, всё же доберусь до починки этого в ближайшие пару недель. Ждите тогда новые графики.
Documentation/networking/timestamping.txt об этом говорит следующее:
Они обещают сообщить пользовательскому приложению момент, когда последний байт данных пройдет "timestamping point". Хотя они упоминают явно только отправку пакета, полагаю что это применимо и к приему.
Лучшая документация по ядру — его исходники. Если разберетесь, обязательно расскажите нам :).
Да, есть и такой способ. Можно после получения (
recv) пакета из сокета дернутьioctlSIOCGSTAMPилиSIOCGSTAMPNSи получить время получения ядром этого пакета. Последнийioctlвозвращаетstruct timespecдопускающую точность до наносекунд, в отличие от первого, который возвращаетstruct timevalс микросекундами.Полученное таким образов время ничем не будет отличаться времени полученного через
SO_TIMESTAMPINGс установленным флагомSOF_TIMESTAMPING_RX_SOFTWARE.Но есть еще один способ получить то же самое, сделав на один системный вызов меньше. Опция сокета
SO_TIMESTAMP(не путать сSO_TIMESTAMPING) включает доставку временных меток в контрольном сообщении. Временные метки те же самые, что и вSIOCGSTAMP.См. Documentation/networking/timestamping.txt