[nuclearcat]

Ну висят сетевые на одном ядре и что? Наблюдаются дропы, ерроры и другие аномалии при работе с сетевой? ksoftirqd выступает?

за 2 дня на eth1 как раз набралось "dropped:1431"

softirq грузит одно ядро до 60%. Ещё не смертельно, но возникает вопрос: нафиг тогда нужны остальные очереди, если в них ничего не попадает...

Попадать будет в зависимости от правил классификации(собственные, у карты). А каковы они, хз, надо в драйвере смотреть.

[shaytan]

Почему в tc, fw классификатор жрёт в 2 раза больше ресурсов проца чем u32 классификатор, хотя количество правил одинаковое?

А количество хитов в эти правила тоже одинаковое?

 

U32 на eth0, pps out 5,68k

FW на eth1, pps out 5,62k

 

Судя по PPS должно быть одинаковым:

При текущем PPS следующие значения:

18838152 28.4798 vmlinux vmlinux fw_classify

13198639 19.9539 vmlinux vmlinux ipt_do_table

13174191 19.9169 vmlinux vmlinux u32_classify

 

[Dark_Angel]

Так у Вас, все очереди по большей части одно ядро и разгребает. Если это вызывает проблему - попробуйте разнести очередь руками по разным процессорам. Благо у Вас их целых 8. А насчет того, что карта не раскладывает пакеты в разные очереди - так видимо не успевает, т.к. генерится прерывание и пакеты уходят из очереди. Что-то мне подсказывает, что там расскладываение происходит по принципу: очередь полная на 30-50-70%, начинаю ложить в другую. А учитывая, что очередь до этого порога видимо не доходит - все собирается в первой попавшейся, максимум во второй.

 

Касательно классификаторов, не понимаю удивления: u32 - самый простой классификатор. Берет кусок пакета и ищет в нем нужное сочетание. fw в данном случае сложнее, нежели просто анализ куска пакета до первого совпадения, тут надо и с ядром поговорить и метку ядра запросить, отсюда и загрузка.

 

Кстати, выше в этой теме я писал, что разнос по процессорам не дает никакого еффекта. Дает - если отдать работу с сетью на последние процессоры, т.к. они загружены как правило меньше всего. Если оставить разнос сетевой на все процессоры, которые, якобы обрабатываю прерывания, когда кто-то первый освободится - это стоит 5-10% суммарного процессорого времени. Так что разносить прерывания нужно, но не на первые процессоры, а на последние. + Прерываний генерится на 10% больше. Пропорция софт/хард прерывания остается неизменной при этом.

Изменено 30 октября, 2009 пользователем Dark_Angel

[DemYaN]

...

Касательно классификаторов, не понимаю удивления: u32 - самый простой классификатор. Берет кусок пакета и ищет в нем нужное сочетание. fw в данном случае сложнее, нежели просто анализ куска пакета до первого совпадения, тут надо и с ядром поговорить и метку ядра запросить, отсюда и загрузка.

...

я б так не сказал - скорее наоборот

nfmark хранится в skb-струтуре которая есть отображение пакета в ядре в течении прохождения оного через сетевой стек. nfmark обычно выставляется нетфильтром и для классификатора остается только сравнить это поле структуры с заданным значением. А в u32 нужно выполнить более сложную задачу - разбор содержимого пакета по смещению и маске.

[Dark_Angel]

2DemYaN: Все правильно говорите, но посмотрите на профайлер. Даже если откинуть момент, что fw_classify зовется в 2.4 раза чаще, чем u32, при одинаковом количестве правил, что само по себе уже навевает на мысли, всеравно, составьте пропорцию и уровняйте их samples. Получите ту же долю процессора.

 

Видимо, несмотря на тривиальный способ поиска, копание в структуре занимает больше времени, чем разобрать пакет, хотя должно быть наоборот, конечно. tc при этом у себя в описании обзывает u32 simplest classifier.

[azlozello]

[root@localhost ~]# uname -a

Linux localhost 2.6.27.25-78.2.56.0.140asp.i686 #1 SMP Tue Jul 7 16:58:15 EDT 2009 i686 i686 i386 GNU/Linux

 

[root@localhost ~]# lspci

01:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)

01:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)

 

[root@localhost ~]# ethtool -i eth2

driver: e1000e

version: 1.0.15-NAPI

firmware-version: 5.11-2

bus-info: 0000:01:00.1

 

[root@localhost ~]# ethtool -i eth3

driver: e1000e

version: 1.0.15-NAPI

firmware-version: 5.11-2

bus-info: 0000:01:00.0

 

Intel® Core2 Quad CPU Q8200 @ 2.33GHz

Иперфом генерится поток ~280kpps пакетами по 64к

Тупой форвардинг.

На проце 0 загрузки.

Дропов нет.

Как это понимать?

[shicoy]

[root@localhost ~]# uname -a

Linux localhost 2.6.27.25-78.2.56.0.140asp.i686 #1 SMP Tue Jul 7 16:58:15 EDT 2009 i686 i686 i386 GNU/Linux

 

[root@localhost ~]# lspci

01:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)

01:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)

 

[root@localhost ~]# ethtool -i eth2

driver: e1000e

version: 1.0.15-NAPI

firmware-version: 5.11-2

bus-info: 0000:01:00.1

 

[root@localhost ~]# ethtool -i eth3

driver: e1000e

version: 1.0.15-NAPI

firmware-version: 5.11-2

bus-info: 0000:01:00.0

 

Intel® Core™2 Quad CPU Q8200 @ 2.33GHz

Иперфом генерится поток ~280kpps пакетами по 64к

Тупой форвардинг.

На проце 0 загрузки.

Дропов нет.

Как это понимать?

А что не так? помоему радоваться надо =)

[azlozello]

Чему же радоваться? На лицо явный глюк :)

Тут у людей и на 150кппс уже тормоза начинаются.

[DemYaN]

На проце 0 загрузки.

Дропов нет.

Как это понимать?

0 - загрузка чего? si, hi ? на каждом ядре?

[azlozello]

Полный и абсолютный 0 по всем направлениям!

Подозреваю глюк где то был.

Переставил другую систему и теперь хоть 20% рисует на ядрах :)

[maxxxxu]

кто-нибудь использует вместе с интеловскими сетевыми данный софт:

Intel® I/O Acceleration Technology Software (IOATDMA)?

Direct Cache Access (DCA)?

Изменено 10 ноября, 2009 пользователем maxxxxu

[nuclearcat]

IO/AT DMA использую, толку от него немного.

DCA - говорят интересная штука, но в бенчмарках не пробовал, нет карт с этой штукенцией.

[vitalyb]

Могу ошибаться, тестов не делал (точнее пару лет назад с DCA просто всё падало, с тех пор не пробовал), но создается впечатление, что обе технологии заточены для "генераторов" и "приемников" трафика, но не маршрутизаторов. IO/AT DMA не нужно в случае роутинга - одна сетевуха в буфер положила данные, вторая - оттуда же забрала, ничего никуда копировать не надо. DCA вообще может оказаться вредной потому как весь пакет в кеше CPU не нужен в принципе - для принятия решения о судьбе пакета достаточно первых байт, payload как правило не нужен.

 

[alexpro]

Хочу продолжить тему, поднятую V@No.

Имеется сетевуха Intel Pro/1000 PT Dual Port (82571EB). На сайте производителя в описании указано: "2Tx, 2Rx queues".

Что бы не пробовал делать на домашнем десктопном компе - не получается вывести в multiqueue режим. Есть ли у кого положительный опыт RX/TX multiqueue с такой сетевушкой?

 

[13:14:12]root@xlin64:/usr/src/e1000e-1.0.15/src/# ethtool -i eth1

driver: e1000e

version: 1.1.2-NAPI

firmware-version: 5.11-2

bus-info: 0000:04:00.0

 

Может, это связано с тем, что я пытаюсь сделать невозможное для десктопного чипсета (i965)?

 

[DemYaN]

e1000e не поддерживает multiqueue

[alexpro]

DemYaN

Странно. Но тогда почему у меня при инициализации e1000e без отдельного хандлера для TX сетевушка занимает 2 MSI-X прерывания, и в /proc/irq записывается для одного eth1-Q0, а для другого просто eth1? Если не поддерживает, зачем такой огород? А если включаешь отдельный хандлер для TX, то сетевушка занимает 3 MSI-x прерывания, eth1-rx eth1-tx и eth1.

Изменено 6 декабря, 2009 пользователем alexpro

[voron]

У 82571, если верить pdf'ке интела, нет msi-x.

[alexpro]

voron

****

e1000e 0000:02:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16

e1000e 0000:02:00.0: setting latency timer to 64

udev: renamed network interface eth0 to eth3

e1000e 0000:02:00.0: irq 35 for MSI/MSI-X

e1000e 0000:02:00.0: irq 36 for MSI/MSI-X

e1000e 0000:02:00.0: irq 37 for MSI/MSI-X

0000:02:00.0: eth0: (PCI Express:2.5GB/s:Width x1) 00:15:17:ae:25:d0

0000:02:00.0: eth0: Intel® PRO/1000 Network Connection

0000:02:00.0: eth0: MAC: 4, PHY: 8, PBA No: 1010ff-0ff

****

А это тогда что?

[DemYaN]

У 82571, если верить pdf'ке интела, нет msi-x.

там есть message signaled interrupts - это оно и есть

http://www.intel.com/products/ethernet/ind...71EB&s3=all

 

2 alexpro

возможно в новых версиях драйвера что-то и изменилось, но http://www.mail-archive.com/e1000-devel@li...t/msg00928.html

Изменено 6 декабря, 2009 пользователем DemYaN

[sirmax]

Тут у людей и на 150кппс уже тормоза начинаются.

150kpps как считать то?

пакет прише, пакет ушел это 1 ппс или 2?

 

У меня сейчас 130кппс на одной сетевке (по 130 на вход и выход ), и по 50 (50 вход, 50 выход) еще на 2-х, при этом роутер уперся в траффик раньше чем в pps имхо...

[voron]

там есть message signaled interrupts - это оно и есть

msi != msi-x, хотя возможно 82571 и поддерживает msi-x

Изменено 6 декабря, 2009 пользователем voron

[DemYaN]

там есть message signaled interrupts - это оно и есть

msi != msi-x, хотя возможно 82571 и поддерживает msi-x

на ссылке, которую привел я - extended message signaled interrupts тобишь MSI-X

[alexpro]

DemYaN

Мда... Стало быть - железка умеет, а драйвер почему-то нет. Попробовать что ли самому поковырять исходник? Или, может, уже нашлись такие умельцы-кулибины? В исходнике e1000e-1.1.2 есть код, отвечающий за создание очередей, я смотрел.

У меня есть еще Intel Pro/1000 на 82574L (встроенная в материнку S3420GPLC). У этой тоже заявлено по 2 очереди на rx и tx. Но с ней та же самая история - выделяется 2 прерывания, одно eth2-Q0, а второе eth2. Непонятно, почему драйвер ведет себя так, как будто multiqueue есть, но вторую очередь не выделяет, ограничившись первой?

 

voron

Судя по доке драйвера - IntMode 0 - legacy, 1 - MSI (default), 2 - MSI-X.

 

****

e1000e 0000:03:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16

e1000e 0000:03:00.0: setting latency timer to 64

0000:03:00.0: : Interrupt Mode set to 2

e1000e 0000:03:00.0: irq 38 for MSI/MSI-X

e1000e 0000:03:00.0: irq 39 for MSI/MSI-X

0000:03:00.0: eth1: (PCI Express:2.5GB/s:Width x1) 00:15:17:ae:25:d0

0000:03:00.0: eth1: Intel® PRO/1000 Network Connection

0000:03:00.0: eth1: MAC: 4, PHY: 8, PBA No: 1010ff-0ff

****

[voron]

на ссылке, которую привел я - extended message signaled interrupts тобишь MSI-X

На ссылке, которую Вы привели, нет ни слова про msi, зато есть внизу ссылка на PDF-ку, в которой в описании чипа нет extended.

Ну а поддержка msi-x чипом в реальности может только радовать.

Изменено 6 декабря, 2009 пользователем voron

[DemYaN]

на ссылке, которую привел я - extended message signaled interrupts тобишь MSI-X

На ссылке, которую Вы привели, нет ни слова про msi, зато есть внизу ссылка на PDF-ку, в которой в описании чипа нет extended.