Jump to content
Калькуляторы

Кто что думает про RPS/RFS в новом ядре linux?

Новость вот http://www.opennet.ru/opennews/art.shtml?num=27497

 

Для меня, прям таки знаковые изменения. До этого думал, что кроме Интела с многоочередными сетевыми, это ни кого не интересует.

хм... опять pppoe краями обошли?

Share this post


Link to post
Share on other sites

В чем же заключается не совсем?

В моем случае это шлюзы L3<=>PPPoE, причем последнее - клиентские соединения на BRAS. Но и не это главное. Вообще сетевых задач достаточно много, и каждая из них заставляет распределить сетевую нагрузку на максимально возможное число ядер, что не всегда удается с помощью железа.

Share this post


Link to post
Share on other sites

Ну пока никто ничего про RPS/RFS не думает, поделюсь своими испытаниями.

Собрал ванильное ядро.

На каждый интерфейс и каждую очередь появился псевдо-файл /sys/class/net/ethX/queues/rx-N/rps_cpus

 

В синтетических тестах показывает конкретно загрузку указанного ядра.

Тест 1, на сервере (переносим нагрузку на CPU15):
# echo 00008000 > /sys/class/net/eth0/queues/rx-0/rps_cpus
# iperf -s -p 555

На клиенте:
# iperf -c 192.168.0.1 -p 555 -t 30

При этом загрузка CPU15 ~7%


Тест 2, на сервере (переносим нагрузку на CPU14 + CPU15):
# echo 0000с000 > /sys/class/net/eth0/queues/rx-0/rps_cpus
# iperf -s -p 555

На клиенте:
# iperf -c 192.168.0.1 -p 555 -t 30

При этом загрузка CPU15 ~7%

Повторяем 2-й тест, но указываем 2 потока для клиента iperf:
# iperf -c 192.168.0.1 -p 555 -t 30 -P 2

При этом загрузка CPU14 ~3,5% CPU15 ~3,5%

Share this post


Link to post
Share on other sites

Транзитному траффику - бесполезно, для pppoe вроде как тоже бесполезно.

Share this post


Link to post
Share on other sites

nuclearcat, почему? RFS - да, не поможет транзитному трафику. А RPS - еще как. Например, в случае развесистых правил iptables.

 

Share this post


Link to post
Share on other sites

IMHO блокировки iptables и неоптимизированные правила имеют слишком большой негативный эффект, RPS врядли это сильно поправит.

Скоро буду проводить тесты на реальном траффике, посмотрим...

Share this post


Link to post
Share on other sites

Запустил на малом боевом сервере (всего ~300 PPPoE соединений).

Каждый PPP-сетевой интерфейс тоже имеет свой псевдо-файл /sys/class/net/pppX/queues/rx-0/rps_cpus, в него записываем маску, и загрузка переходит на указанные ядра.

Вывод: RPS на PPPoE работает, на маршрутизации тоже.

Share this post


Link to post
Share on other sites
Сравнительные показатели производительности в студию ! :-)
Не знаю насколько смогу дать прям сравнительные показатели, но пока могу поделиться субъективными.

Боевой сервер, ~3000 ppp-интерфейсов, сетевая intel/igb, по 4 очереди на прием/4 на передачу. Загружена только первая очередь по приему и первая по передаче. К 12-ти часам дня эти ядра в полку, полная паника, аут.

Для того чтобы всё работало, добавляем еще сетевую с двумя интерфейсами, конфигурируем по одной очереди на прием и одной на передачу, получаем 3 интерфейса, 6 ядер задействуем - полёт нормальный.

 

А теперь новый вариант - одна сетевая, по одной очереди на прием и передачу + RSP на все оставшиеся ядра, итого - очень некислый рост производительности и загрузка _всех_ без исключения ядер. Это пока тоже теория, т.к. в бою на больших серверах не проверял еще ;)

Share this post


Link to post
Share on other sites

загрузка _всех_ без исключения ядер.

Загрузка может быть как раз от того что контексты потоков переключаются или от особенностей синхронизации.

Share this post


Link to post
Share on other sites

Ivan_83, если при этом одно ядро было загружено скажем на 60%, а теперь каждое из четырех ядер загружено на 30%, то можно считать что это неплохой результат.

 

Share this post


Link to post
Share on other sites

Ivan_83, если при этом одно ядро было загружено скажем на 60%, а теперь каждое из четырех ядер загружено на 30%, то можно считать что это неплохой результат.

Если 4 ядра загружены на 30%, то загрузка одного ядра должна была быть 4х30=120%, чего при равном трафике и ппс - быть не может. Но это я не к тому что всё плохо, а как раз таки наоборот :) Если ядро в полку до паники в системе, включаем RPS, и все продолжает работать как ни в чем не бывало, распределяя нагрузку по указанным ядрам.

Share this post


Link to post
Share on other sites
Если 4 ядра загружены на 30%, то загрузка одного ядра должна была быть 4х30=120%, чего при равном трафике и ппс - быть не может
Хорошо, если бы это было правдой, но это не так. :) Ivan_83 как раз об этом и написал. Здесь еще можно говорить о false sharing-е (http://en.wikipedia.org/wiki/False_sharing) - явлении, которое убивает все преимущества кеша процессора в SMP системе, когда у каждого процессора (не важно что там, физический процессор или ядро) свой кеш (не shared).

 

Share this post


Link to post
Share on other sites

Итак, поэкспериментировал у себя. Тазик - pptp сервер с accel-pptp, кол-во сессий - около 100 (конечные клиенты общаются через 4 магистральных роутера - на 3 из них много клиентов, на 4-м - чуток), проц - атлон 3600+ (самое слабое 2-ядерное, что было в хозяйстве, да еще и с раздельным и мелким кешем), сетевуха - Yukon2 (). Результаты ниже:

 

Изначально:

CPU0: 0.0% usr 0.1% sys 0.0% nic 73.7% idle 0.0% io 0.0% irq 27.0% sirq

CPU1: 0.0% usr 0.1% sys 0.0% nic 99.6% idle 0.0% io 0.0% irq 0.1% sirq

После echo 00000003 >/sys/class/net/eth0/queues/rx-0/rps_cpus:

CPU0: 0.1% usr 0.1% sys 0.0% nic 81.4% idle 0.0% io 0.0% irq 18.9% sirq

CPU1: 0.0% usr 0.0% sys 0.0% nic 88.8% idle 0.0% io 0.0% irq 11.1% sirq

После for i in `ls /sys/class/net`; do echo 00000003 >/sys/class/net/$i/queues/rx-0/rps_cpus; done:

CPU0: 0.3% usr 0.9% sys 0.0% nic 80.6% idle 0.0% io 0.0% irq 17.9% sirq

CPU1: 0.3% usr 1.5% sys 0.0% nic 85.9% idle 0.0% io 0.0% irq 12.0% sirq

После echo 00000000 >/sys/class/net/eth0/queues/rx-0/rps_cpus:

CPU0: 0.0% usr 0.1% sys 0.0% nic 77.2% idle 0.0% io 0.0% irq 22.5% sirq

CPU1: 0.0% usr 0.1% sys 0.0% nic 93.6% idle 0.0% io 0.0% irq 6.1% sirq

Значения прыгают естессно, выбраны были примерно средние; ошибка +- 1-2% softirq.

Т.е. фактически - некоторый оверхед распараллеливания имеется, но не такой уж и большой. Наиболее эффективным является включение RPS на eth0, включение его на всех ppp интерфейсах при этом практически ничего не меняет; а включение его исключительно на ppp - дает только незначительное распараллеливание (отчего-то).

С вланами еще не экспериментировал - переведу продакшн сервера на 2.6.35, тогда и посмотрю. Хотя - на тех машинах оно не сильно заметно будет (недавно на квадкоры феномы проапгрейдил).

 

При указании маски 02 (неважно, для eth0 или для всех) - нагрузка весьма занятно распределяется:

CPU0: 0.1% usr 0.5% sys 0.0% nic 90.8% idle 0.0% io 0.0% irq 8.3% sirq

CPU1: 0.1% usr 0.0% sys 0.0% nic 75.9% idle 0.0% io 0.0% irq 23.8% sirq

Интересно, что же включено в нагрузку на eth0 - неужто столько отжирает обслуживание самой сетевой карты?

 

Включение RFS с таблицей на 64к записей на eth0 - заметного улучшения не дало (что в принципе и ожидалось)

 

P.S. Теперь придется думать - как бы автоматизировать включение RPS на том дистре, что крутится на серверах (LEAF, debian-based с древним инитом из эпохи 2.2 ядер если не ошибаюсь).

Edited by NiTr0

Share this post


Link to post
Share on other sites

Ну и есть тут кто нибудь кому RSP на PPPoE Bras-е выигрыш по производительности дал?

Share this post


Link to post
Share on other sites

Интересно как оно согласуется с irq affinity? По умолчанию ведь стоит FF - прерывания раскидываются по ядрам. Наскольно я понимаю сначала надо привязывать прерывания к ядрам , а после этого раскидывать через RPS softirq ?

Share this post


Link to post
Share on other sites

кто-то еще тестирует? интересны результаты. сами недавно переехали на 2.6.35 - честно говоря улучшений не видно... даже наоборот. но подозреваю исключительно от того что основные ресурсы жрут на машине не сетевые процессы, а юзер и кернел левел приложения.

Share this post


Link to post
Share on other sites

Занимательно. На сервере встроенные Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet на драйвере bnx2 - тут видно:

# ls -1 /sys/class/net/eth0/queues/
rx-0
rx-1
rx-2
rx-3
rx-4
rx-5
rx-6
rx-7

И не встроенные Intel Corporation 82571EB Gigabit Ethernet Controller на драйвере e1000e, однако:

# ls -1 /sys/class/net/eth2/queues/
rx-0

 

Есть мысли, почему для bnx2 появилось количество очередей = количеству процессорных ядер, а для интеля нет?

Edited by heap

Share this post


Link to post
Share on other sites
а должно было появиться?

Уже дочитался, что не должно. Написано примерно так "Для поддерживающих аппаратно очереди - появятся очереди". А для неподдерживаемых появится очередь как раз rx-0.

Откуда возникают вопросы:

1. Таки кто-то заметил оптимизацию от этого RPS, там где очереди не появились?

2. Почему, если указанный бродком с драйвером bnx2 умеет очереди, они раньше не появлялись ни в каком виде, в том время как 10Г бродком с драйвером bnx2x появлялся в /proc/interrupts в виде интераптов на заданное количество очередей?

Share this post


Link to post
Share on other sites

Будьте любезны, пожалуйста, по подробнее про 10G бродком....

Я то же такой хочу))))

 

а должно было появиться?

Уже дочитался, что не должно. Написано примерно так "Для поддерживающих аппаратно очереди - появятся очереди". А для неподдерживаемых появится очередь как раз rx-0.

Откуда возникают вопросы:

1. Таки кто-то заметил оптимизацию от этого RPS, там где очереди не появились?

2. Почему, если указанный бродком с драйвером bnx2 умеет очереди, они раньше не появлялись ни в каком виде, в том время как 10Г бродком с драйвером bnx2x появлялся в /proc/interrupts в виде интераптов на заданное количество очередей?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this