История изменений

Там нет роутинга! Если включить 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% и там дропы уже серьезные.

Там нет роутинга! Если включить 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% и там дропы уже серьезные.