Потеря пакетов, вызванная OpenSSL?Странное использование процессора - PullRequest
Новая
       3

Потеря пакетов, вызванная OpenSSL?Странное использование процессора

3 голосов
/ 08 декабря 2011

Я пишу сетевое приложение, читая пакеты из UDP-сокетов, а затем расшифровываю их с помощью OpenSSL.

Основная функция выглядит так: 

receive(){
    while(1){
        read(udp_sock);
        decrypt_packet();
    }
}

Программа работала нормально, пока ядобавлено шифрование.Теперь между буфером ядра и моим приложением потеряно много пакетов (netstat -su - RcvbufErrors: 77123 и продолжает расти;).Пакеты довольно большие (60 КБ), и я пытаюсь использовать их в сети Ethernet 1 Гбит / с (поэтому проблема начинается после превышения 100 Мбит / с)

Звучит нормально - расшифровка занимает слишком много времени, а пакеты приходят слишком быстро.Проблема в том, что загрузка ЦП никогда не превышает 30% как для отправителя, так и для получателя.

Проблема исчезает после комментирования этого утверждения в decrypt_packet (): AES_ctr128_encrypt ();

Мой вопрос - возможно ли, что OpenSSL использует некоторый набор инструкций, которые не учитываются вИспользование процессора (я использую htop и системный монитор Gnome)?Если нет, то что еще может вызвать такую ​​потерю пакетов, если мощность процессора все еще доступна для обработки?

Ответы [ 2 ]

2 голосов
/ 13 декабря 2011

Используя профилировщик, я смог решить проблему.OpenSSL использует специальный набор инструкций, которые выполняются в специальной части CPU.Показано, что загрузка ЦП была низкой, но на самом деле она занималась шифрованием, поэтому мое приложение не могло прочитать системный буфер достаточно быстро.

Я переместил расшифровку в другой поток, который решил проблему.И теперь поток, обрабатывающий все шифрование, показан как постоянно использующий 0% CPU.

2 голосов
/ 09 декабря 2011

Сколько ядер процессора у вашей системы? Ваш код однопоточный? Это может быть максимальное использование одного ядра и, следовательно, использование только 25% доступного процессора.

...