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

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

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

 

Или я не прав?

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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, не правда ли?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

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

Edited by Умник

Share this post


Link to post
Share on other sites
но о каких переключениях контекста может идти речь, если ядро занято исключительно обработкой прерываний?
само прерывание это и есть переключение контекста.
Получается, даже без NAPI и каких-либо хитрых настроек e1000e применяет interrupt mitigation?
А модуль точно без NAPI собран?
При получении первого пакета в обработчике прерываний дальнейшие прерывания запрещаются и устанавливается время опроса. До истечения этого времени пакеты будут накапливаться, поэтому их можно забрать все вместе.
Не видел в драйвере в этом районе никаких времён.
То есть либо тюните драйвер ручками до посинения, либо, если вам наплевать на загрузку CPU, включайте NAPI.
Одно другому совершенно не мешает. У меня NAPI + InterruptThrottleRate отлично работает.

 

Edited by voron

Share this post


Link to post
Share on other sites
само прерывание это и есть переключение контекста.
Почему же тогда у меня cs много меньше in(terrupts)?

 

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

 

Share this post


Link to post
Share on other sites
<br />
само прерывание это и есть переключение контекста.
Почему же тогда у меня cs много меньше in(terrupts)?
Потому что это счётчик чистых переключений контекста(вытесняемая многозадачность и тп). Прерывание это переключение контекста априори - выполнение текущей задачи прерывается и управление передаётся в обработчик прерывания.
А модуль точно без NAPI собран?
Абсолютно.
Речь о e1000e? objdump -t e1000e.ko |grep napi что-то говорит?

Share this post


Link to post
Share on other sites
Речь о e1000e? objdump -t e1000e.ko |grep napi что-то говорит?
Ничего. Нету там napi.

 

Share this post


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

 

Или я не прав?

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

 

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites
Речь о 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.

"

Share this post


Link to post
Share on other sites

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

Edited by voron

Share this post


Link to post
Share on other sites
NAPI is enabled by default.
Драйвер собран с -DNONAPI. Просто в e1000 (e1000e) по умолчанию InterruptThrottleRate=3 (dynamic conservative mode, но можно ручками прописать количество прерываний в секунду). Таким образом сама карточка умеет ограничивать максимальное количество прерываний в секунду, и задается это значение драйвером.

 

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

Share this post


Link to post
Share on other sites
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 by nag-f

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