Предыстория:
В местной локалке админ жаловался, что linux-роутеры не справляются с возросшей нагрузкой. Нагрузка была 3-5 интерфейсов с 90мбитами в час-пик.
Фаервол был уже либо минимизирован, либо отсутствовал. Сетевые Intel 82558 с NAPI понизили нагрузку, но ненадолго. Роутеры на 2.4 ядре и загрузка 30-90% в system.
Имеем сетевую Compaq на чипе 82558.
Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 05)
Subsystem: Compaq Computer Corporation NC3121 Fast Ethernet NIC (WOL)
Flags: bus master, medium devsel, latency 32, IRQ 22
Memory at 44200000 (32-bit, prefetchable) [size=4K]
I/O ports at 1000 [size=32]
Memory at 44000000 (32-bit, non-prefetchable) [size=1M]
Expansion ROM at 44900000 [disabled] [size=1M]
Capabilities: [dc] Power Management version 1
Админ набрал их штук 20-30 по 25 грв, и, как показала практика, не прогадал. После ковыряния в драйверах стало ясно, что CPU Saver'а сия карточка не имеет.
Почитав про NAPI и зная, что карточка работает в NAPI, посмотрев на ethtool ethtool -g eth1
Ring parameters for eth1:
Pre-set maximums:
RX: 256
RX Mini: 0
RX Jumbo: 0
TX: 256
Current hardware settings:
RX: 256
RX Mini: 0
RX Jumbo: 0
TX: 128
я увидел, что есть буфера для TX и RX по 256 пакетов. В драйвере вычитал, что под каждый пакет берётся 2к памяти, итого 2к*256 пакетов TX + 2k * 256 пакетов RX = 1M,
что отлично согласовалось с Memory at 44000000 (32-bit, non-prefetchable) [size=1M] из lspci. Долго читал и вдумывался в NAPI. В нескольких строчках его суть:
- пришло прерывание от сетевой по получению пакета - запретили прерывания по приходу пакетов, прошедулили полл и закончили обработку прерывания.
- между прерыванием и поллингом могут прийти ещё пакеты
- при полле читаем не более max(dev_weight,dev_budget) пакетов из буфера.
- если приняли или подтвердили передачу хотя бы 1 пакета - возвращаем 1. В этом случае ядро вызовет нас ещё раз - это и есть поллинг.
- если пакетов нет - разрешаем прерывания, возвращаем 0 и выходим из поллинга. В этом случае выигрыш только в том случае, если пакеты пришли между прерыванием и поллом, или между поллами.
В результате работы этого алгоритма имеем 5-10 RX пакетов на прерывание, хотя можем иметь 256 :). Ну и соответственно при pps >30k имеем 3-7k прерываний в секунду только с одного интерфейса. А нагруженных интерфейсов 3 и более. Вот и получаем
картину, когда 2GHz процессор не справляется даже с NAPI - его душат прерывания. Какой выход - сделать меньше прерываний :) в ущерб отклику.
Вопрос в том - как? Задать частоту поллинга устройств у меня не получилось. Что остаётся - затормозить поллинг. Те пришло прерывание, запретили его и шедулим полл не сразу, а через
нужный таймаут. Простой расчёт 100Мбит/(60байт на пакет * 8 бит)=208333.(3) pps теоретически. Разделив это число на 256 пакетов, которые можно поместить в буфер,
получим ~ 814 поллов в секунду. Значит, задержки поллинга < 1мс должно хватить, чтобы вытянуть 100Мбит минимальными пакетами без потерь по переполнению буферов. Осталось реализовать это в драйвере.
Вспомнив баг с таймером в esfq, я подумал - а почему бы и мне не использовать этот же таймер. Его дискретность - переменная HZ при сборке ядра - обычно принимает значения
100, 250 или 1000. Соответственно при частоте 100 я не смогу принимать&передавать >25k pps с одного интерфейса, однако при такой частоте тиков таймера я буду иметь максимум 100 прерываний в секунду с каждого интерфейса.
Для частоты 1000Hz - максимум 1000 прерываний в секунду с каждого интерфейса.
Осталось дело за реализацией. При приходе прерывания по приёму пакета добавляем таймер через минимальный интервал времени. При срабатывании таймера шедулится полл. Между прерыванием и поллом сетевая продолжает принимать пакеты в буфер в обход CPU.
В результате, когда полл наконец-то вызывается, ему есть чему порадоваться - буфер заполнен гораздо больше, чем без использования таймера. И полл одним махом его принимает. Следующий полл с большой вероятностью увидит 0 пакетов и опять включит прерывания и завершит поллинг.
Первый же пакет прерыванием замкнёт цикл. При использовании этой схемы естественно возрастёт отклик. Например, при HZ=100 пинг растёт с 0.2 мс до 10мс и может достигать 20 мс. При HZ=1000 пинг остаётся в пределах 2мс, что является допустимым.
Ну а вот и патч на драйвер e100 от Intel версии 3.5.17 (или тут)
Ну а дальше всё стандартноcd /usr/src
wget http://downloadmirror.intel.com/df-support/2896/eng/e100-3.5.17.tar.gz
tar xzf e100-3.5.17.tar.gz
cd e100-3.5.17/src
wget http://vorona.com.ua/articles/e100_poll_linux/e100.patch
patch -p0 -i e100.patch
make CFLAGS_EXTRA=-DE100_NAPI
Намеренно не делаем инсталл. Если есть возможность - лучше подсунуть модуль ручками через insmod, зайдя не через e100 интерфейс.
Не забываем про увеличение dev_weight echo 256 > /proc/sys/net/core/dev_weight
и вписываем его в boot-скрипты.
Как мне сообщил админ, модуль e100 от intel (независимо от наличия или отсутствия патча) на 2.4.x ядрах загружается со 2-го раза :D
Модуль работает без проблем как на 2.4.24, так и на 2.6.19. SMP пока не проверялся, но проблем быть не должно - изменения в коде минимальны и легко прослеживаются.
Ну и о самом главном. После загрузки модуля при HZ=100 на 2.4 LA упал с 1.5-2 до 0.1-0.2 и утилизация процессора упала с 60-90% до 10-20% в system. Роутер можно сказать ожил :D
На 2.6.19 при HZ=1000 эффект был не такой умопомрачительный, но вполне достаточный, чтобы дочитать до конца эту статью. Теперь наши роутеры не боятся ядрёных pktgen'ов и прочих страшных вещей :).
Отдельное спасибо sirmax'у за предоставленные идеи, роутеры и пиво для поддержания проекта :D