VS> Hашел я процессор с AESNI, но что-то я что загружаю aesni.ko, что выгружаю его VS> - результат "openssl speed aes-128-cbc" совершенно одинаковый. Видимо что-то VS> делаю или понимаю не так.
Как сказано в man aesni, оно влияет на ядерную подсистему crypto(4).
Hа самом деле openssl даже на процессорах без AES-NI, но с поддержой всяческих SSE/MMX/AVX очень здорово ускоряет вычисления за счет использования 128-битной арифметики, если она доступна.
Перед тем, как разобрался с этим, почитав сорцы, я имел неосторожность погонять openssl speed -evp aes-128-cbc -elapsed на системе с ZFS (но без GELI) и поддержкой AES-NI в процессоре, в разных комбинациях загружая/выгружая aesni.ko и cryptodev.ko параллельно с работой файловой системы и словил креш с ребутом на очередном прогоне openssl speed. Сервер удалённый без консоли и запись крешдампов не была включена, так что на чём конкретно оно срубилось, сказать точно не могу. Теоретически ZFS может для вычисления крипто-хешей использовать crypto(9), туда не лазил.
Вообще это опасно, конечно, делать то, что я делал - пока ядро не использует регистры CPU, с которыми работают эти наборы команд (SSE/MMX/AVX/AESNI), то при переключении контекста из приложения в ядро и обратно в то же приложение, ядро не обязательно сохранять и восстанавливать все эти регистры для экономии времени. Hо если ядро начинает их использовать, то приходится. Что будет, если ядро в лице ZFS или ещё какого потребителя crypto(9) начнет использовать такие регистры, а потом выбить у него из под ног табуреточку одновременно запуская openssl speed... Вполне какой-нибудь assert() мог сработать, ну или просто скрешиться из-за дедлока какого.
