Ты выбираешь ARM-платформу под VPN, хеширование или защищённое хранилище. В спецификации указан отдельный Qualcomm Crypto Engine. Кажется, что он разгрузит процессор. Но в тесте SHA-256 этот ускоритель потратил 4,85 секунды против 0,10 секунды у ARMv8 Crypto Extensions — почти в 48 раз больше.
Задача покупателя — понять, можно ли записать QCE в обоснование закупки. Короткий ответ: пока нельзя. Считай криптографическую производительность по возможностям CPU, а отдельный блок принимай в расчёт только после теста на целевой версии Linux.
Ускоритель не добавил пропускной способности
Первый результат QCE выглядел ещё хуже: 10,76 секунды реального времени на SHA-256 против 0,10 секунды у ARMv8 CE. Процессорного времени тест с QCE потребовал 5,14 секунды, вариант с инструкциями CPU — те же 0,10 секунды.
После отката патчей блокировки BAM время QCE сократилось до 4,85 секунды. Регрессию ослабили, но отставание от ARMv8 CE осталось почти 48-кратным.
Для закупки это важнее внутреннего устройства драйвера. Отдельный криптоблок не гарантирует большей пропускной способности: в опубликованном тесте QCE не только считал дольше, но и тратил больше процессорного времени, чем хеширование через инструкции ARMv8.
Поэтому фразу поставщика «есть аппаратное криптоускорение» нельзя переводить в число VPN-туннелей, запросов в секунду или гигабайтов хешируемых данных. Между наличием блока на кристалле и рабочей производительностью в Linux стоит драйвер. Здесь он стал узким местом.
Поддержка драйвера остаётся спорной
Эрик Биггерс из Google предложил удалить из ядра около 3,5 тысячи строк драйвера QCE. Разработчики ядра называли драйвер сломанным и вредным; среди причин обсуждали низкую скорость, ошибки и другие ограничения.
Но драйвер пока нельзя считать удалённым. По меньшей мере один разработчик готов его сопровождать, а обсуждение продолжается; за советом по процедуре также обращались к Грегу Кроа-Хартману.
Кшиштоф Козловский возразил, что предложенный коммит неполон и что удалять QCE для заявленной цели необязательно. Патчи на удаление обсуждают не первый месяц, однако согласованного решения из переписки не следует.
Значит, у закупки два независимых риска. Первый уже измерен: QCE проиграл CPU-инструкциям в тесте SHA-256. Второй пока не реализовался, но его нельзя игнорировать: поддержка драйвера в будущих ядрах остаётся предметом спора.
Защищённые ключи нужно проверять отдельно
Поставщик может обосновать QCE не скоростью, а работой с ключами. Само наличие криптоблока этого не подтверждает: ядро Linux не поддерживает использование QCE для защищённых ключей.
Linux умеет работать с аппаратно обёрнутыми ключами через inline crypto engines. Такой механизм применяют в Android, но это другая связка оборудования и драйверов — её нельзя автоматически приписать QCE.
Если платформа нужна для защищённого хранилища, запроси название механизма, алгоритм, версию ядра и драйвер, который передаёт операции в аппаратный блок. Ответ «в SoC есть QCE» ничего не говорит о доступности защищённых ключей в твоём Linux.
Как записать требования в спецификацию
Базовую производительность считай по ARMv8 Crypto Extensions. Для SHA-256 опубликованный ориентир — 0,10 секунды у ARMv8 CE против 4,85 секунды у QCE после отката проблемных патчей и 10,76 секунды до отката. Это не универсальный бенчмарк для любой нагрузки, но достаточное основание не начислять QCE производительность авансом.
В запрос поставщику добавь четыре требования:
- тест на выбранной версии ядра и дистрибутиве;
- тот же алгоритм и размер данных, которые будут в рабочей нагрузке;
- результаты с QCE и без него, включая реальное и процессорное время;
- статус сопровождения драйвера для всего срока эксплуатации платформы.
Если поставщик не даёт воспроизводимых результатов, записывай QCE как неподтверждённую возможность. Сервер или шлюз должен выдерживать расчётную нагрузку без него. Пересчитать конфигурацию в пользу ускорителя можно после теста — не после чтения спецификации.
