Глупый вопрос: NAPI

[Умник]

Подскажите, зачем нужен NAPI в Linux? Он дает какую-то экономию? Если да, то каким образом? Все время считал, что poll-ить всегда дороже, чем тупо обрабатывать прерывания. Насколько я понял, NAPI может улучшить общую производительность системы (за счет шедулинга), в случае если от карты поступает много прерываний, а у меня всего одно ядро и я не хочу, чтобы тормозил юзерспейс и вообще остальная система. Но на роутерах сейчас ядро обычно целиком отдается на растерзание карте, и это не проблема.

 

Или я не прав?

 

[voron]

NAPI грубо это приём > 1 пакета за 1 прерывание. При большом pps обычно поллить гораздо дешевле - пакеты итак придут, только систему не будут душить переключения контекста и обработка десятков тысяч прерываний.

[Умник]

voron, но о каких переключениях контекста может идти речь, если ядро занято исключительно обработкой прерываний? Вот пример с роутера без NAPI, юзерспейса почти нет:

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
0  1      0 564824   3340  13680    0    0     2     3  562   32  3 46 51  0
0  0      0 564660   3344  13704    0    0     0     4 22550   59  2 51 47  0
1  0      0 564424   3344  13704    0    0     0     0 26799   44  0 61 39  0
0  0      0 564788   3344  13704    0    0     0     0 24451   27  2 50 48  0

Ничтожное значение cs, не правда ли?

[Умник]

Кстати, интересный момент. В выводе vmstat ~25k прерывний в секунду, хотя через роутер в это время проходило ~100k PPS. Получается, даже без NAPI и каких-либо хитрых настроек e1000e применяет interrupt mitigation?

[EvilShadow]

Подскажите, зачем нужен NAPI в Linux? Он дает какую-то экономию? Если да, то каким образом? Все время считал, что poll-ить всегда дороже, чем тупо обрабатывать прерывания.

Не всегда. При получении первого пакета в обработчике прерываний дальнейшие прерывания запрещаются и устанавливается время опроса. До истечения этого времени пакеты будут накапливаться, поэтому их можно забрать все вместе. В то же время прерывания от сетевухи в этот промежуток времени приходить не будут, а значит, система не будет тратить на них ресурсы. А при простое сети прерывания разрешаются вновь, поэтому на лишние опросы ресурсы тоже не тратятся.

[Умник]

EvilShadow, для e1000 похожего эффекта можно добиться при помощи параметра InterruptThrottleRate и его друзей. В e1000(e).txt еще есть замечание интересное:

If CPU utilization is not a concern, use RX_POLLING (NAPI) and default driver settings.

То есть либо тюните драйвер ручками до посинения, либо, если вам наплевать на загрузку CPU, включайте NAPI.

Edited December 10, 2009 by Умник

[voron]

но о каких переключениях контекста может идти речь, если ядро занято исключительно обработкой прерываний?

само прерывание это и есть переключение контекста.

Получается, даже без NAPI и каких-либо хитрых настроек e1000e применяет interrupt mitigation?

А модуль точно без NAPI собран?

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

Не видел в драйвере в этом районе никаких времён.

То есть либо тюните драйвер ручками до посинения, либо, если вам наплевать на загрузку CPU, включайте NAPI.

Одно другому совершенно не мешает. У меня NAPI + InterruptThrottleRate отлично работает.

 

Edited December 10, 2009 by voron

[Умник]

само прерывание это и есть переключение контекста.

Почему же тогда у меня cs много меньше in(terrupts)?

 

А модуль точно без NAPI собран?

Абсолютно.

 

[voron]

<br />

само прерывание это и есть переключение контекста.

Почему же тогда у меня cs много меньше in(terrupts)?

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

А модуль точно без NAPI собран?

Абсолютно.

Речь о e1000e? objdump -t e1000e.ko |grep napi что-то говорит?

[Умник]

Речь о e1000e? objdump -t e1000e.ko |grep napi что-то говорит?

Ничего. Нету там napi.

 

[nag-f]

Подскажите, зачем нужен NAPI в Linux? Он дает какую-то экономию? Если да, то каким образом? Все время считал, что poll-ить всегда дороже, чем тупо обрабатывать прерывания. Насколько я понял, NAPI может улучшить общую производительность системы (за счет шедулинга), в случае если от карты поступает много прерываний, а у меня всего одно ядро и я не хочу, чтобы тормозил юзерспейс и вообще остальная система. Но на роутерах сейчас ядро обычно целиком отдается на растерзание карте, и это не проблема.

 

Или я не прав?

Прерывания и исключения нарушают нормальный ход выполнения программы, потому, что процессор вынужден в первую очередь обрабатывать внешние события или сообщения о возникновении особых усло­вий или ошибок. При этом рвется конвейер выполнения команд в процессоре, ну что такой разрыв конвейра - это считайте 30 тактов на выходе конвейреа не будет результата, в случае если конвейер имеет 30 ступеней. Также сбрсывается содержимое регистров стека вызовов, изменяется содержимое кэшей... вобщем плохая штука эти прерывания, но это только в том случае, если иметь хотябы базовы представления о работе вычислительных систем :)

 

[voron]

Речь о e1000e? objdump -t e1000e.ko |grep napi что-то говорит?

Ничего. Нету там napi.

значит остаётся предположить, что эта сетевая принимает несколько пакетов за 1 прерывание и без NAPI.

[nag-f]

Речь о e1000e? objdump -t e1000e.ko |grep napi что-то говорит?

Ничего. Нету там napi.

значит остаётся предположить, что эта сетевая принимает несколько пакетов за 1 прерывание и без NAPI.

Остается всеголишь прочитать README к драйверу.

 

"

NAPI

----

NAPI (Rx polling mode) is supported in the e1000e driver. NAPI is enabled

by default.

"

[voron]

enabled так, что objdump -t e1000e.ko|grep napi молчит? Или ?

Edited December 10, 2009 by voron

[Умник]

NAPI is enabled by default.

Драйвер собран с -DNONAPI. Просто в e1000 (e1000e) по умолчанию InterruptThrottleRate=3 (dynamic conservative mode, но можно ручками прописать количество прерываний в секунду). Таким образом сама карточка умеет ограничивать максимальное количество прерываний в секунду, и задается это значение драйвером.

 

Из этого топика я понял, что основаная цель NAPI - "умерить" прерывания. Но зачем он нужен при наличии такого функционала?

[nag-f]

NAPI is enabled by default.

Драйвер собран с -DNONAPI. Просто в e1000 (e1000e) по умолчанию InterruptThrottleRate=3 (dynamic conservative mode, но можно ручками прописать количество прерываний в секунду). Таким образом сама карточка умеет ограничивать максимальное количество прерываний в секунду, и задается это значение драйвером.

 

Из этого топика я понял, что основаная цель NAPI - "умерить" прерывания. Но зачем он нужен при наличии такого функционала?

 

С этого надо было начинать.

 

Во первых: интерфейс NAPI не дает процессу захвата пакетов использовать все процессорное время и вызывать ситуацию "тупика" и может быть вполне полезен даже на сетевых картах с аппаратной поддержкой объединения прерываний.

 

Во вторых: Что бы вручную регулировать InterruptThrottleRate и еще порядка 10-ти параметров.. необходимо четко учитывать: размер приемного буфера, pps, максимальную пропускную способность, производительность процессора... я очень сомневаюсь что ради праздного любопытства это стоит делать :)

 

P.S. Я тут довольно часто наблюдаю горячие споры о том, какая ОС лучше в качестве софт роутера. FreeBSD или Linux. Ответ на этот вопрос очень прост, лучше та под которую наиболее оптимально написаны драйвера используемых вами сетевых интерфейсных карт :) Впрочем не удержусь и скажу, что Linux NAPI более интеллектуальный механизм, чем тупой polling FreeBSD:)

Edited December 11, 2009 by nag-f