Танін Антон

Науковий керівник: канд. техн. наук, старший викладач кафедри прикладної математики, статистики на економіки, Нарадовий В.В.

Кіровоградський державний педагогічний університет імені Володимира Винниченка

Анотація: В статті розглядається мережевий стек операційної системи Linux, його налаштування, отримання даних зі стеку та організація моніторингу мережі.

Ключові слова: Linux, мережевий стек, моніторинг, мережа, дані.

Актуальність теми. Використання рівнів мережевого стеку, як засобів моніторингу мережі для збільшення швидкості обробки даних.

Мета роботи. Організувати моніторинг мережі на основі операційної системи Linux з використанням мережевого стеку. Для досягнення мети поставлено такі завдання:

1. Визначити основні поняття підсистеми мережевого пристрою;
2. Розглянути та зробити аналіз мережевого пристрою;
3. Зробити огляд основних основних механізмів керування пакетами;

Мережевий стек влаштований складно, і не існує універсального рішення на всі випадки життя. Якщо критично важливі продуктивність і коректність при роботі з мережею, то доведеться інвестувати чимало часу, сил і засобів в те, щоб зрозуміти, як взаємодіють один з одним різні частини системи.

Підсистему мережевого пристрою в Linux можна розділити на три основні механізми – SoftIRQ, Receive Packet Steering (RPS) та Receive flow steering (RFS). SoftIRQ - механізм виконання коду поза контекстом обробника переривань, реалізованого драйвером. Дана система важлива, тому що апаратні переривання можуть бути відключені протягом усього або частини часу виконання обробника. Receive Packet Steering (RPS) - це програмна реалізація RSS. Receive Packet Steering (RPS) може входити в потік тільки після пакета, витягнутого з DMA-області пам'яті. Receive flow steering (RFS) - механізм управління прийнятими потоками, який використовується спільно з RPS.

Високорівневий шлях, по якому проходить пакет від прибуття до приймального буфера сокету виглядає так:

• Драйвер завантажується та ініціалізується.
• Пакет прибуває з мережі в мережеву карту.
• Пакет копіюється (за допомогою DMA) в кільцевої буфер пам'яті ядра.
• Генерується апаратне переривання, щоб система дізналася про появу пакета в пам'яті.
• Драйвер викликає NAPI, щоб почати цикл опитування (poll loop), якщо він ще не розпочато.
• На кожному CPU системи працюють процеси ksoftirqd. Вони реєструються під час завантаження. Ці процеси витягують пакети з кільцевого буфера за допомогою виклику NAPI-функції poll, зареєстрованої драйвером пристрою під час ініціалізації.
• Очищаються (unmapped) ті області пам'яті в кільцевому буфері, в які були записані мережеві дані.
• Дані, надіслані безпосередньо в пам'ять (DMA), передаються для подальшої обробки на мережевий рівень у вигляді 'skb'.
• Якщо включено управління пакетами, або якщо в мережевій карті є кілька черг прийому, то фрейми входять мережевих даних розподіляються по декількох CPU системи.
• Фрейми мережевих даних передаються з черги на рівні протоколів.
• Рівні протоколів обробляють дані.
• Дані додаються в буфери прийому, прикріплені до сокета рівнями протоколів.

SoftIRQ – система, яку можна представити у вигляді серії потоків ядра (по одному на CPU), в яких працюють функції-обробники, зареєстровані для різних SoftIRQ-подій. Якщо ви коли-небудь піднімалися нагору і зустрічали ksoftirqd / 0 в списку потоків ядра, то це якраз тред SoftIRQ, що виконується на CPU 0.  Підсистеми ядра (наприклад, по роботі з мережею) можуть реєструвати обробника SoftIRQ за допомогою виконання функції open_softirq. Далі ми побачимо, як система по роботі з мережею реєструє своїх SoftIRQ-обробників. А тепер давайте трохи поговоримо про те, як працює SoftIRQ.

Механізм Receive Packet Steering (RPS) працює так, що CPU не витрачатиме менше часу на обробку переривань або циклу poll, але в ньому можна розподіляти навантаження по обробці пакетів після того, як вони були зібрані, і знижувати тривалість роботи CPU в мережевому стеку. RPS генерує для вхідних даних хеш, щоб визначити, який CPU повинен їх опрацювати. Потім дані містяться до вхідної черги (backlog) цього процесора в очікуванні подальшої обробки. У процесор з backlog передається міжпроцесорне переривання (IPI), що ініціює обробку черги, якщо це ще не робиться. RPS розподіляє навантаження по обробці пакетів між декількома CPU, але один великий потік здатний монополізувати час обробки і обмежувати більш дрібні потоки. Обмеження потоків дозволяють лімітувати кількість пакетів від одного потоку, які розміщені в backlog. В результаті маленькі потоки можуть оброблятися паралельно з набагато більшими.

Механізм Receive flow steering (RFS) використовується спільно з RPS. RPS намагається розподіляти вхідні пакети серед кількох CPU, але не бере до уваги питання локальності даних для збільшення частоти потрапляння в кеш CPU. Якщо вам потрібно збільшити цю частоту, то в цьому допоможе механізм RFS, переадресує пакети одного потоку на один і той же CPU. Роботу RFS можна апаратно прискорювати. Мережева карта і ядро ​​можуть спільно визначати, який потік на якому CPU потрібно обробляти. Але для прискорення потрібно визначити, чи підтримується ця функція мережевою картою і драйвером.

Для реалізації організації моніторингу мережі за допомогою мережевого стеку було використано дистрибутив Ubuntu 16.04 LTS та основні засоби терміналу Linux. Додатково використовувались засіб netif_receive_skb та функції ndo_rx_flow_steer, get_rps_cpu, ntuple filtering, igb_set_ethtool_ops.

Список літератури:

1. Мониторинг и настройка сетевого стека Linux [Електронний ресурс] – Режим доступу до ресурсу: https://habrahabr.ru/company/mailru/blog/314168/#7.
2. Illustrated Guide to Monitoring and Tuning the Linux Networking Stack: Receiving Data [Електронний ресурс] – Режим доступу до ресурсу: https://blog.packagecloud.io/eng/2016/10/11/monitoring-tuning-linux-networking-stack-receiving-data-illustrated/.
3. NAPI [Електронний ресурс] – Режим доступу до ресурсу: https://wiki.linuxfoundation.org/networking/napi.
4. Прямой доступ к памяти [Електронний ресурс] – Режим доступу до ресурсу: https://goo.gl/N0daEb.
5. Receive Packet Steering (RPS) [Електронний ресурс] – Режим доступу до ресурсу: hhtp://goo.gl/Xw0K5Gcontent_copyCopy short URL

 

 

Відомості про авторів:

Танін Антон Євгенійович – студент VI курсу фізико-математичного факультету Кіровоградського державного педагогічного університету імені Володимира Винниченка.