0

У меня возникло сомнение во время чтения о планировании NAPI в сетевых драйверах.Кто делает Napi scheduling

Как правило, весь код обработки сети работает в контексте softirq. И с помощью механизма опроса NAPI драйвер будет опросить пакеты после того, как поступит прерывание.

Итак, если код NAPI также работает в контексте softirq, как его можно планировать. (Так как контекстный код прерывания не может быть запланирован).

И какое использование рабочих очередей в сетевых драйверах.

ответ

4

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

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

Когда устройство прерывает:

  • прерывание вызывает переход ядра-режим, если уже не в режиме ядра
  • в Код обработки прерываний linux находит вашу процедуру обработки прерываний вашего драйвера и вызывает ее.
  • Ваш обработчик прерываний вызывает napi_schedule (размещения функции опроса в списке и запуская softirq.
  • Ваши прерывания обработчик возвращает.
  • Просто, прежде чем вернуться в пользовательский режим (или любой другой процессор делает до прерывания), код обработки прерываний видит, что сетевой softirq должен запускаться и активировать его.
  • Softirq вызывает функцию опроса для обработки входящих пакетов, пока у вас не будет пакетов или пока не будет исчерпан бюджет «NAPI». В последнем случае softirq позже повторно ссылается на поток ksoftirqd [я думаю].)
  • Тогда ваш драйвер будет только повторно активировать прерывания на вашем устройстве, если он завершит обработку всех готовых к процессу пакетов.

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

Например, в драйвере intel ixgbe, если драйвер обнаруживает, что сетевой адаптер должен быть сброшен, для повторной инициализации сетевого адаптера запускается запись рабочей очереди. Некоторые из операций требуют относительно длительного сна, и вы не хотите связывать процессор в контексте softirq, если вы можете позволить запустить другую задачу. Могут быть и другие причины - например, вам необходимо выделить большие объемы памяти, которые могут потребовать вызова распределения в контексте задачи.