Исправление blind_oracle, (текущая версия) :
Там нет роутинга! Если включить br_netfilter, то в iptables/forward будут попадать пакеты из бриджа.
Ок, но мне думается что в этом режиме будет нагрузка выше. Но все равно попробую.
реордеринг пакетов неприятен внутри потока. Если поток обрабатывается на одном ядре то и реордеринга не должно быть. Не может ли пригодиться это? Возможно rps+rfs дадут пользу.
Да, внутри потока. А т.к. хеш RSS несимметричен, то прямое направление потока (src->dst) попадет в один воркер сурикаты, а обратное (dst->src) в другой воркер.
По поводу ссылки не совсем понял что конкретно там может помочь :) RPS+RFS хорошая штука, но опять же в том случае если симметрия не парит.
И еще на интеле шаманили с «ethtool rx-flow-hash X flow-type X»
Это не совсем то, с асимметричностью потоков не поможет бороться насколько я понимаю. Читал какие-то статьи про Random Secret Key и его подстройку для того чтобы RSS становился симметричен (https://www.ndsl.kaist.edu/~kyoungsoo/papers/TR-symRSS.pdf например), но пока руки не дошли. Проблема то у меня где-то в другом месте.
Интересно во время тестирования запустить «perf record — sleep 30». Может какую аномалию покажет.
Гляну, спс.
Не пробовал посмотреть сколько pps ловит без потерь просто анализ потока ( без «форвардинга» )?
Что интересно форвардинг практически не влияет не дропы, т.к. дропать начинает именно принимающая карта когда 1 ядро на котором висит ее очередь не справляется с обработкой.
Причем интересно, что загрузка ядра этого идет по какой-то интересной кривой, вроде экспоненты. Т.е. при 1.15Mpps нагрузка 10-20%, а при 1.5Mpps (это максимум что я выжал из tcpreplay) упирается в 100% и там дропы уже серьезные.
Исходная версия blind_oracle, :
Там нет роутинга! Если включить br_netfilter, то в iptables/forward будут попадать пакеты из бриджа.
Ок, но мне думается что в этом режиме будет нагрузка выше. Но все равно попробую.
реордеринг пакетов неприятен внутри потока. Если поток обрабатывается на одном ядре то и реордеринга не должно быть. Не может ли пригодиться это? Возможно rps+rfs дадут пользу.
Да, внутри потока. А т.к. хеш RSS несимметричен, то прямое направление потока (src->dst) попадет в один воркер сурикаты, а обратное (dst->src) в другой воркер.
По поводу ссылки не совсем понял что конкретно там может помочь :) RPS+RFS хорошая штука, но опять же в том случае если симметрия не парит.
И еще на интеле шаманили с «ethtool rx-flow-hash X flow-type X»
Это не совсем то, с асимметричностью потоков не поможет бороться насколько я понимаю. Читал какие-то статьи про Random Secret Key и его подстройку для того чтобы RSS становился симметричен (https://www.ndsl.kaist.edu/~kyoungsoo/papers/TR-symRSS.pdf например), но пока руки не дошли. Проблема то у меня где-то в другом месте.
Интересно во время тестирования запустить «perf record — sleep 30». Может какую аномалию покажет.
Гляну, спс.
Не пробовал посмотреть сколько pps ловит без потерь просто анализ потока ( без «форвардинга» )?
Что интересно форвардинг практически не влияет не дропы, т.к. дропать начинает именно принимающая карта когда 1 ядро на котором висит ее очеред не справляется с обработкой.
Причем интересно, что загрузка ядра этого идет по какой-то интересной кривой, вроде экспоненты. Т.е. при 1.15Mpps нагрузка 10-20%, а при 1.5Mpps (это максимум что я выжал из tcpreplay) упирается в 100% и там дропы уже серьезные.