[xpasha]

Всем доброго дня,

 

Поделитесь пожалуйста информацией, кто имел опыт работы с 10G картами Intel, конкретно у меня X520-SR1 две штуки. Под эту карту с sourceforge скачивается и компилируется под текущее ядро в Линукс системе драйвер ixgbe.ko, последняя версия 3.17.3, в более ранних драйверах в описании к сорцам было упоминание, что драйвер можно собрать с NAPI и тогда к версии драйвера добавлялся постфикс NAPI, с версии если не ошибаюсь 3.10.15 опциональную сборку с NAPI упразднили и судя по сорцам драйвера NAPI там собирается по умолчанию. Ладно с этим вроде удалось разобраться, непонятен остается вопрос, если драйвер собран с NAPI означает ли это, что драйвер будет работать в режиме NAPI в любом случае и не требуется как-то этот режим активировать/деактивировать. Ведь настройка параметрой драйвера осуществляется строкой в /etc/modprobe.conf

 

options ixgbe IntMode=2,2 InterruptThrottleRate=30000,30000 RSS=16,16 DCA=2,2

 

Если карта работает в режиме NAPI то играет ли какую-то роль параметр InterruptThrottleRate? Это ведь параметр регулирующий максимальное число прерываний в секунду если не ошибаюсь и применяется он в режиме отложенных прерываний, аналогичный параметр есть у других карт Интел, но в режиме NAPI он как бы не имеет смысла. Как убедиться, что NAPI работает и нужно ли как-то этот режим активировать? Что еще в этом драйвере есть полезного для повышения производительности сетевухи?

 

P.S. Ссылка на источник на sourceforge - http://sourceforge.net/projects/e1000/ Кстати в Интеле сказали, что под Линукс драйверы они не поддерживают. Типа все в комьюнити.

Изменено 26 сентября, 2013 пользователем xpasha

[vitalyb]

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

 

Еще можно покрутить ethtool -C по части прерываний и латентности, известные оффлоады и hw виртуализацию выключить, а при большом желании повозиться - выпилить atr и самому раскидать flow'ы по прерываниям, но существенных улучшений, скорее всего, не будет.

[xpasha]

Так как эти два метода работают совместно? У них же и принцип работы то совершенно разный. Или механизм NAPI начинает использоваться только на относительно больших загрузках сетевого адаптера?

 

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

 

Еще можно покрутить ethtool -C по части прерываний и латентности, известные оффлоады и hw виртуализацию выключить, а при большом желании повозиться - выпилить atr и самому раскидать flow'ы по прерываниям, но существенных улучшений, скорее всего, не будет.

[xpasha]

Обнаружил еще одну странность. При загрузках порядка 2Гбит начинаются резкие скачки загрузки процессора с 20% до примерно 50%. Кто-нибудь может сказать в чем дело? Наверняка из присутствующих на этом форуме немало народа работает с 10G картами от Intel. Прикладываю к посту соответствующие скриншоты из Заббикса.

[Ilya Evseev]

1) какой процессор и как прерывания распределены по ядрам?

желательно, чтобы все обработчики прерываний выполнялись на ядрах с общим кэшем.

smp_affinity используется?

 

2) ITR=1 пробовали?

[voron]

Хоть тема и старая, но не очень :)

Обнаружил еще одну странность. При загрузках порядка 2Гбит начинаются резкие скачки загрузки процессора с 20% до примерно 50%. Кто-нибудь может сказать в чем дело? Наверняка из присутствующих на этом форуме немало народа работает с 10G картами от Intel. Прикладываю к посту соответствующие скриншоты из Заббикса.

у меня это были ksoftirqd в топе. Источник - входящий pps. 4 ksoftirqd висят в топе и тормозят всё и сами себя, карта теряет пакеты. По результатам perf top -> _raw_spin_lock_irqsave и гугля набрел на тред мейлилиста e1000, где человеку посоветовали выключить IOMMU. Ребутнулся с параметром ядра iommu=off - помогло. Из хинтов intel'а - включение ntuple filters через ethtool для аппаратного распределения трафика между очередями.