Ключевые слова:poll, linux, ethernet, interface, optimization, speed, patch, (найти похожие документы)
From: Ворона Александр <http://vorona.com.ua/>;
Date: Mon, 13 Mar 2007 14:31:37 +0000 (UTC)
Subject: Добавление поддержки polling в драйвер e100 для Linux
Оригинал: http://vorona.com.ua/articles/e100_poll_linux/index.php
Предыстория:
В местной локалке админ жаловался, что 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 (или тут)
--- e100.c 2006-12-27 10:18:02.000000000 +0200
+++ e100.c 2007-01-14 18:45:01.000000000 +0200
@@ -178,7 +178,7 @@
#define PFX DRV_NAME ": "
#define E100_WATCHDOG_PERIOD (2 * HZ)
-#define E100_NAPI_WEIGHT 16
+#define E100_NAPI_WEIGHT 256
MODULE_DESCRIPTION(DRV_DESCRIPTION);
MODULE_AUTHOR(DRV_COPYRIGHT);
@@ -596,6 +596,7 @@
u16 eeprom[256];
spinlock_t mdio_lock;
u32 pm_state[16];
+ struct timer_list poll_timer;
};
static inline void e100_write_flush(struct nic *nic)
@@ -942,7 +943,7 @@
static void e100_get_defaults(struct nic *nic)
{
struct param_range rfds = { .min = 16, .max = 256, .count = 256 };
- struct param_range cbs = { .min = 64, .max = 256, .count = 128 };
+ struct param_range cbs = { .min = 64, .max = 256, .count = 256 };
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;
}
+static void my_rx_shedule(unsigned long arg)
+{
+ struct net_device *netdev = (struct net_device *)arg;
+ __netif_rx_schedule(netdev);
+}
+
static irqreturn_t e100_intr(int irq, void *dev_id, struct pt_regs *regs)
{
struct net_device *netdev = dev_id;
@@ -1984,7 +1991,13 @@
#ifdef CONFIG_E100_NAPI
if(likely(netif_rx_schedule_prep(netdev))) {
e100_disable_irq(nic);
- __netif_rx_schedule(netdev);
+ //__netif_rx_schedule(netdev);
+ //---------
+ nic->poll_timer.data = (unsigned long)dev_id;
+ nic->poll_timer.function = my_rx_shedule;
+ nic->poll_timer.expires = jiffies;//next timer tick - each 1/HZ ms
+ add_timer(&nic->poll_timer);
+ //--------
}
#else
e100_rx_clean(nic, NULL, 0);
@@ -2114,6 +2127,8 @@
e100_hw_reset(nic);
free_irq(nic->pdev->irq, nic->netdev);
del_timer_sync(&nic->watchdog);
+ //удаляем poll-таймер
+ del_timer(&nic->poll_timer);
netif_carrier_off(nic->netdev);
e100_clean_cbs(nic);
e100_rx_clean_list(nic);
@@ -2720,6 +2735,8 @@
netdev->dev_addr[0], netdev->dev_addr[1], netdev->dev_addr[2],
netdev->dev_addr[3], netdev->dev_addr[4], netdev->dev_addr[5]);
+ //только в случае успеха инициализируем 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
