NAPI против адаптивных прерываний

Может ли кто-нибудь объяснить, как две следующие технологии используются для уменьшения издержек прерывания при высокой сетевой нагрузке?

1. Adaptive-RX / Adaptive-TX, и
2. NAPI;

Я был бы признателен за ответ, который объясняет разницу ближе к исходному уровню ядра Linux? Также мне хотелось бы услышать, как заставить сетевой адаптер переключаться в режим опроса / прерывания при нагрузке ~ 400 Мбит / с.

Больше фона:

Кажется, проблема в том, что драйверы bnx2 и e1000 игнорируют команду ethtool -C adaptive-rx on. Вероятно, это связано с тем, что эти драйверы не поддерживают адаптивные прерывания. Хотя в справочном руководстве по Broadcom Programmer сказано, что эта функция должна поддерживаться аппаратным обеспечением NIC BCM5709.

Поэтому я решил попробовать NAPI и уменьшить вес с 64 до 16 в вызове функции netif_napi_add (), чтобы принудительно установить сетевой адаптер в режиме опроса при значительно меньшей нагрузке, но, к сожалению, это не сработало. Я предполагаю, что NAPI не нуждается в какой-либо специальной аппаратной поддержке в NIC, это правильно?

Я использую аппаратное обеспечение BCM5709 (оно использует драйвер bnx2). А ОС это Ubuntu 10.04. Процессор XEON 5620.

Основной принцип модерации прерываний состоит в том, чтобы генерировать менее одного прерывания на каждый принятый кадр (или одно прерывание на завершение кадра передачи), уменьшая издержки ОС, возникающие при обслуживании прерываний. Контроллер BCM5709 поддерживает несколько аппаратных методов для объединения прерываний, в том числе:

• Генерировать прерывание после получения X-кадров (rx-кадров в ethtool)
• Генерировать прерывание, когда больше кадров не получено после X usecs (rx-usecs в ethtool)

Проблема с использованием этих аппаратных методов заключается в том, что вам нужно выбрать их для оптимизации пропускной способности или задержки, у вас не может быть обоих. Генерация одного прерывания для каждого принятого кадра (rx-frames = 1) минимизирует задержку, но это происходит при высоких затратах с точки зрения издержек на обслуживание прерывания. Установка большего значения (скажем, rx-frames = 10) уменьшает количество циклов ЦП, потребляемых путем генерации только одного прерывания для каждых десяти полученных кадров, но вы также столкнетесь с более высокой задержкой для первых кадров в этой группе из десяти.

Реализация NAPI пытается использовать тот факт, что трафик поступает в виде пакетов, так что вы сразу генерируете прерывание для первого полученного кадра, а затем немедленно переключаетесь в режим опроса (то есть отключаете прерывания), потому что позади будет больше трафика. После того, как вы опросили какое-то количество кадров (16 или 64 в вашем вопросе) или некоторый интервал времени, драйвер снова включит прерывания и начнет заново.

Если у вас прогнозируемая рабочая нагрузка, то можно выбрать фиксированные значения для любого из вышеперечисленных (NAPI, rx-frames, rx-usecs), которые дают вам правильный компромисс, но большинство рабочих нагрузок варьируются, и вы в конечном итоге делаете некоторые жертвы. Это где Adaptive-RX / Adaptive-TX вступают в игру. Идея заключается в том, что драйвер постоянно контролирует рабочую нагрузку (количество кадров в секунду, размер кадра и т. Д.) И настраивает схему объединения аппаратных прерываний для оптимизации задержки в ситуациях с низким трафиком или оптимизации пропускной способности в ситуациях с высоким трафиком. Это классная теория, но ее сложно реализовать на практике. Лишь немногие водители реализовать (см http://fxr.watson.org/fxr/search?v=linux-2.6&string=use_adaptive_rx_coalesce ) и водители bnx2 / E1000 не в этом списке.

Для хорошего описания того, как должно работать каждое объединяющее поле ethtool, взгляните на определения структуры ethtool_coalesce по следующему адресу:

http://fxr.watson.org/fxr/source/include/linux/ethtool.h?v=linux-2.6#L111

Для вашей конкретной ситуации (пропускная способность ~ 400 Мбит / с) я бы предложил настроить значения rx-frames и rx-usecs для наилучших настроек для вашей рабочей нагрузки. Посмотрите как на издержки ISR, так и на чувствительность вашего приложения (httpd? Etc.) к задержке.

Дейв