Всем привет! Я хочу поделиться анализом существующих технологий Intel, которые позволяют максимально быстро передать трафик из физической карты на виртуальную машину. В принципе, все способы опробованы в реальности на картах Intel XL710, поэтому я так же скажу об их плюсах и минусах. И поскольку наша компания занимается в том числе разработкой виртуального свитча, все это с точки зрения виртуального свитча.

Intel SR-IOV

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


С помощью использования 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.