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

SMP, распределение irq, reordering, rps на карточках с одной очередью

Имеется такой конфиг сервера:

2xXeon E5450 и две сетевые карты:

# lspci | grep -i eth
03:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12)
05:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12)

У этих карточек всего одна очередь.

 

В /proc/interrups такая картина:

# cat /proc/interrupts | grep -i eth
 68:  480285318  480619071  480774892  481265904  482006358  481431514  480912831  480838626   PCI-MSI-edge      eth0
 69:  428111727  427778819  427615122  427126705  426379290  426959434  427481810  427555201   PCI-MSI-edge      eth1

 

# cat /proc/irq/68/smp_affinity_list 
0-7
# cat /proc/irq/69/smp_affinity_list 
0-7

 

Правильно ли я понимаю, что в этом случае возможен реордеринг пакетов, т.к. пакеты засовываются сетевой картой в одну очередь, а прерывания обрабатываются различными ядрами по очереди(или случайно)?

 

И не ошибаюсь ли в том, что для того, чтобы избавиться от реордеринга, нужно прибить ethX к конкретному ядру (и включить rps(который балансирует per-hash-flow), если одного ядра не хватает)?

Share this post


Link to post
Share on other sites

Одну сетёвку на одно ядро, другую на другое, должно хватить даже так.

Share this post


Link to post
Share on other sites

Одну сетёвку на одно ядро, другую на другое, должно хватить даже так.

 

откуда такая уверенность? по-моему случай как раз из тех, когда RPS - "то, что доктор прописал". только мапить надо не по принципу "всё на всё", а пробовать и смотреть как распределяется нагрузка.

Share this post


Link to post
Share on other sites

Пример: E3-1220 + две встроенных сетевки intel, трафик до 800М в пиках, сетевушки прибиты к ядрам, включен rps. Утилизация проца программными прерываниями до 50%. Ставим еще одну карточку Intel 576, ограничиваем на ней количество очередей до 1 объединенной rxtx и строим bonding, перекрепляем сетевушки к ядрам с учетом новых реалий и отказываемся от rps. В итоге даже наливая 1.1Г получаем утилизацию до 40%. Вывод: rps не панацея, правда rps в моем случае был включен скорее автоматически, нежели по нужде.

 

P.S. А что касается очередей - попробуйте поиграться включением msi.

 

 

Edited by passer

Share this post


Link to post
Share on other sites

Меня больше интересует вопрос про реордеринг. Если очередь одна и она через smp_affinity(а не через rps) прибита к нескольким процессорам, то получаем потенциальное перемешиваение пакетов. Или я ошибаюсь?

Share this post


Link to post
Share on other sites

А смысл? Ладно бы не хватало пары ядер для дела. Так нет же, хватает, как правило. Другое дело, что хочется экспериментов, тогда - да, дело познавательное.

Share this post


Link to post
Share on other sites

Пока хватает, но и трафика пока там мало, когда в этом месте будет что-то современное, неизвестно.

Сервер и карточки дохлые как видно из топика(жалкие однопортовые broadcom и очень древние Xeon). Сейчас smp_affinity раскидывает весь трафик по всем CPU, при том не per-flow судя по тому как хорошо балансируются прерырвания. Я подозреваю, что в этом случае возможна перестановка пакетов(из-за чего могут жаловаться на скорость на tcp-потоках), поэтому хочу отказаться от smp_affinity для раскидывания по CPU и вместо него сделать RPS. Интересуюсь мнением и опытом людей, потому что раньше почти не работал с таким барахлом.

Share this post


Link to post
Share on other sites

Я на Xeon E54xx обычно более 600-700M не наливаю. Особенно, если мамка типа S5000VSA или аналог. Вылазили грабли всякие, причем даже при смене сетевушек на приличные Intel 82576. А может у меня руки не туда закруглились...

 

 

 

 

 

 

 

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

smp_affinity никакого отношения к RPS не имеет

это понятно. зря я наверное в одном топике их упомянул

 

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

Это Вы про RPS или про размазывание прерываний по всем CPU через smp_affinity?

 

Кстати, нашёл топик 2002-го года на эту тему http://www.gossamer-threads.com/lists/linux/kernel/292775

Share this post


Link to post
Share on other sites

Это Вы про RPS или про размазывание прерываний по всем CPU через smp_affinity?

это о smp_affinity. Даже со включенным RPS надо прибивать прерывание только к одному ядру. Топик относится к 2.4 и драйверам без NAPI - такое поискать еще надо :)

Share this post


Link to post
Share on other sites

Интересно, как пакеты перемешивались на 2.4-ом ядре? Не выполнялись же прерывания одновременно на нескольких CPU. Какой механизм синхронизации в 2.6(и 3.x), гарантирующий отсутсвие перестановок?

Share this post


Link to post
Share on other sites

откуда такая уверенность?

Практика, даже E7400 с ширпотребной мамкой и 2мя r8169 800 мегабит/~100 Kpps (router+htb)

Share this post


Link to post
Share on other sites

Наверное не по теме.

1)Но двухпроцессорные конфигурации не очень для роутера

2)Е54хх не очень по производительности

3)Броадком хуже реалтека (сетевухи виснут при нагрузке 700Мбит/с)

 

Стоит поменять материнку хоть на сандибридж i3-i7, хоть со встроенным реалтеком - и будет результат. На электричестве сэкономите...

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