Використання технологій від Intel для передачі мережевого трафіку з фізичної адаптера у віртуальний

Всім привіт,

Я хочу поділитися аналізом існуючих технологій Intel, які дозволяють максимально швидко передати трафік з фізичної карти на віртуальну машину.
В принципі, всі способи випробувані в реальності на картах Intel XL710, тому я так само скажу про їх плюси і мінуси. І оскільки наша компанія займається в тому числі розробкою віртуального світча, все це з точки зору віртуального світча.

Intel SR-IOV

Не зовсім технологія Intel, але пощупати вдалося тільки їх реалізацію.
Коротенько, фізичний адаптер (PF) ділиться на кілька віртуальних (VF).
Трафік усередині одного vlan за замовчуванням не виходить за межі PF, і забезпечує найбільш мінімальні затримки порівняно з віртуальними адаптерами на софтових бриджах.

ДрайвериVF — це пристрій PCI, прокидываемое у віртуальну машину. Віртуальна машина повинна мати драйвер i40e, інакше підчепити її вона не зможе. Правда в докери можна тупо закинути в netns.


З допомогою використання Intel FlowDirector в принципі можна змінити поведінку і вказати правила, за якими трафік повинен ходити між VF або назовні PF.
Також можна зробити ручне розподіл трафіку за RX черг або хардварный дроп трафіку відразу при вході на карту.
Підтримка конфігурації flow є в драйверах, але окремого api конкретно для Flow Director я не знайшов.
Хто хоче погратися — можна покопатися в исходниках ethtool, або використовувати Intel DPDK, в ньому API реалізований, але карта відчіплюється від kernel драйвера з усіма витікаючими.

З моєї точки зору, ці технології в основному для адмінів, яким просто треба зменшити затримки при передачі трафіку між віртуальними машинами.

Плюси: робота в VMWare, так і KVM. Скрізь швидше софтових бриджів як за затримок, так і пропусной здібності. І CPU не жере.
Мінуси: віртуальний світч у цьому кейсі — потрібно перетворювати в реальний на окремому залозі, куди встромляються PF від сервера з віртуальними машинами.
І 64 VF на один PF зараз досить мало.

Intel DPDK

Про даний development kit на хабре вже були статті, тому особливо поширюватися не буду. Але в контесті віртуальних машин, інформації досить мало.
Я розберу основні способи використання Intel DPDK у разі якщо потрібно передати трафік між фізичною адаптером і віртуальним.
Дана технологія для нас є основною, так як ми робимо Openflow світч.
Ну і далі під віртуальною машиною я маю на увазі KVM c DPDK додатком усередині, так як на гіпервізор VMWare особливо не поставиш нічого, а всередині віртуальної машини VMWare вибору особливо немає, e1000 або vmxnet3. Я раджу vmxnet3.

Intel порадував нас такими можливостями

Спосіб 1: Pain
Технічно представляє з себе один з двох.

Можна підчепити свій віртуальний світч через TAP, а в якості віртуального адаптера використовувати e1000, і якщо всередині VM DPDK додаток — цеплятся до нього через igb pmd.



Можна підчепити свій віртуальний світч через TAP, а в якості віртуального адаптера використовувати virtio-net, і якщо всередині VM DPDK додаток — цеплятся до нього через virtio pmd.



Плюси цих методів: простота, працює як з DPDK додатками, так і зі звичайними.
Мінуси: продуктивність просто біль, багато копіювань, багато переходів усередині віртуальної машини і context switching.

Спосіб 2: Fast & Furios
Можна підчепити свій віртуальний світч через IVSHMEM (в Qemu раніше треба було патчити, зараз начебто влито), а в якості віртуального адаптера створювати спеціалізований адаптер DPDK Ring, який є найбільш швидким IPC механізмом між DPDK додатками.



Плюси: краща продуктивність
Мінуси: тільки DPDK програми

Спосіб 3: One size fits all

Можна підчепити свій віртуальний світч через vhost-user API, а в якості віртуального адаптера використовувати virtio-net.



Плюси: працює як з DPDK додатками, так і з звичайними, продуктивність хороша (але гірше способу 2, у разі якщо всередині VM DPDK додаток)
Мінуси: в основному пов'язані з лінк статусами та іншими обвязками, вирішувані

Спосіб 4: Arcane
Intel DPDK також пропонує спосіб — створення KNI пристрою.
У двох словах є окремий kernel модуль, який організовує soft rx/tx черги, створює віртуальний адаптер з цими чергами і забезпечує копіювання skb_buf в mbuf і назад, емулюючи роботу мережі.
Ми досі його досліджуємо, поки остаточних результатів немає.
Але вже відомі:
Плюси: можна скомбінувати з DPDK ring, для legacy створювати KNI, для DPDK залишати ring. Можна створити KNI поверх фізичної карти.
Мінуси: як то не дуже їде, CPU жере тоннами і особливих переваг не видно.
Але ми працюємо над цим.

Will keep you posted.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.