From: Ворона Александр <http://vorona.com.ua/>
Date: Mon, 13 Mar 2007 14:31:37 +0000 (UTC)
Subject: Добавление поддержки polling в драйвер e100 для Linux
Предыстория:
В местной локалке админ жаловался, что 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 (или тут)
pci_read_config_byte(nic->pdev, PCI_REVISION_ID, &nic->rev_id);
/* MAC type is encoded as rev ID; exception: ICH is treated as 82559 */
@@ -1962,6 +1963,12 @@
return 0;
}
+ //только в случае успеха инициализируем poll-таймер
+ init_timer(&nic->poll_timer);
return 0;
err_out_free:
Ну а дальше всё стандартно
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
929 Прочтений • [Добавление поддержки polling в драйвер e100 для Linux (poll linux ethernet interface optimization speed patch)] [08.05.2012] [Комментариев: 0]
Vova
