Основний принцип модерації переривань - генерувати менше одного переривання на отриманий кадр (або одного переривання на завершення кадру передачі), зменшуючи накладні витрати ОС, що виникають при обслуговуванні переривань. Контролер 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? Тощо) до затримки.
Дейв