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


12

Чи не могли б хто-небудь пояснити, як дві наступні технології використовуються для пом'якшення переривань накладних витрат під великим навантаженням у мережі?

  1. Adaptive-rx / Adaptive-tx і
  2. NAPI;

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

Докладніше:

Здається, проблема полягає в тому, що драйвери bnx2 та e1000 ігнорують команду "ethtool -C adaptive-rx on". Це, мабуть, тому, що ці драйвери не підтримують адаптаційні переривання. Хоча посилання в посібнику програміста Broadcom говорить, що ця функція повинна підтримуватися обладнанням BCM5709 NIC.

Тож я вирішив спробувати NAPI і зменшити вагу з 64 до 16 у виклику функції netif_napi_add (), щоб змусити NIC у режимі опитування при набагато меншому навантаженні, але, на жаль, це не вийшло. Я здогадуюсь, що NAPI не потребує спеціальної апаратної підтримки в NIC, це правильно?

Обладнання, яке я використовую, є BCM5709 NIC (він використовує драйвер bnx2). А ОС - Ubuntu 10.04. Процесор - XEON 5620.

Відповіді:


18

Основний принцип модерації переривань - генерувати менше одного переривання на отриманий кадр (або одного переривання на завершення кадру передачі), зменшуючи накладні витрати ОС, що виникають при обслуговуванні переривань. Контролер BCM5709 підтримує декілька методів апаратного забезпечення для з’єднання переривань, включаючи:

  • Створити переривання після отримання X кадрів (rx-кадри в ettool)
  • Створити переривання, коли більше X кадрів не буде отримано після X usecs (rx-usecs в ethtool)

Проблема використання цих апаратних методів полягає в тому, що вам потрібно вибрати їх для оптимізації пропускної здатності або затримки, ви не можете мати обох. Генерування одного переривання для кожного прийнятого кадру (rx-кадри = 1) мінімізує затримку, але це робиться з високою вартістю з точки зору накладних витрат на переривання. Встановлення більшого значення (скажімо, rx-кадри = 10) зменшує кількість споживаних циклів процесора, генеруючи лише один перерив на кожні десять отриманих кадрів, але ви також зустрінете більшу затримку для перших кадрів у цій групі з десяти.

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

Якщо у вас є передбачувана навантаження, то для будь-якого з перерахованих вище (NAPI, rx-кадри, rx-usecs) можна вибирати фіксовані значення, які дають вам правильний компроміс, але більшість навантажень змінюються, і ви в кінцевому підсумку робите деякі жертви. Тут вступають у гру адаптив-rx / adaptive-tx. Ідея полягає в тому, що водій постійно контролює навантаження (отримані кадри в секунду, розмір кадру тощо) і налаштовує апаратну схему переривання переривання, щоб оптимізувати затримку в ситуаціях з низьким трафіком або оптимізувати пропускну здатність у великих дорожніх ситуаціях. Це крута теорія, але може бути складно реалізувати на практиці. Лише декілька драйверів реалізують його (див. Http://fxr.watson.org/fxr/search?v=linux-2.6&string=use_adaptive_rx_coalesce ) та драйвери bnx2 / e1000 відсутні у цьому списку.

Щоб отримати хороший опис того, як має працювати кожне поле для злиття етилу, ознайомтеся з визначеннями структури ethtool_coalesce за наступною адресою:

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

Для вашої конкретної ситуації (~ 400Mb / s пропускна здатність) я б запропонував налаштувати rx-кадри та rx-usecs значення для найкращих налаштувань для вашої роботи. Подивіться як на накладні витрати ISR, так і на чутливість вашої програми (httpd? Тощо) до затримки.

Дейв


1
Ви сказали, що "Реалізація NAPI намагається використати той факт, що трафік надходить в пучки, так що ви генеруєте переривання негайно на першому отриманому кадрі , а потім негайно переходите в режим опитування ". Але у wiki сказано, що NAPI ніколи не використовує апаратні переривання, а опитує кожні певний проміжок часу : en.wikipedia.org/wiki/New_API Точна цитата: "Ядро може періодично перевіряти прихід вхідних мережевих пакетів, не перериваючись. , що виключає накладну обробку переривання ". Де правда?
Олексій

1
@Alex Hardware перебої повинні використовуватися для повідомлення ядра про отримання трафіку. Отриманий пакет "старого стилю" обробника графіків переривань перезавантажень повторно включає переривання. Обробник переривання NAPI відключає переривання, планує опитування та повторно вмикає переривання. Опитувач виконує отримання пакетів для певної кількості пакетів, і доки трафік для обслуговування запитувача продовжує працювати, метою є запобігання жорстких переривань, завжди відтягуючи трафік від NIC. Коли трафік згасає, пиллер виходить з ладу, і система повертається в очікування перерви.
suprjami
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.