The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Добавление поддержки polling в драйвер e100 для Linux (poll linux ethernet interface optimization speed patch)


<< Предыдущая ИНДЕКС Правка src / Печать Следующая >>
Ключевые слова: 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

<< Предыдущая ИНДЕКС Правка src / Печать Следующая >>

 Добавить комментарий
Имя:
E-Mail:
Заголовок:
Текст:




Спонсоры:
Слёрм
Inferno Solutions
Hosting by Ihor
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2019 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру