Как стать автором
Обновить

Комментарии 31

Видимо хабру такое не интересно…
Наткнулся на эту статью случайно, обычно просматриваю все заголовки появившихся статей на хабре через RSS.
Возможно непопулярность связана с тем, что никто и не видел, что эта статья появилась?

Может за одно подскажите, двухпортовый i40e на DPDK16.04 принимает примерно только 50% всех пакетов на доном порту, на другом все ок.
Процент не принимаемых пакетов не зависит от нагрузки и всегда одинаков.
Сложно заванговать — пишите в скайп, обсудим.

Если это Intel XL710, то там надо собрать ядро с INTEL_IOMMU_DEFAULT_ON и добавить intel_iommu=on параметр загрузки.
Там обычно используется PCI-to-PCI мост, который криво мапится через uio_pci_generic вышеупомянутым образом, в принципе если выгрузить драйвер моста, потом подгрузить VFIO и UIO вместо pci_generic родным скриптом dpdk_nic_bind.py, то по идее должно нормально стать (об этом тоже написано в статье).

На 40GbE интерфейсах pci_generic как-то никак плоховато работает.

Я сейчас переписываю bsd socket'ы на DPDK, что бы был полный dropin replacement, и можно было использовать как OpenOnload — поставил, подгрузил, и старый-бодрый nginx 38Gbit кушает на ура.

Надеюсь что статья была полезной.

p.s. обновите прошивку карты.
Да, использую XL710, подгружаю igb_uio без vfio через родной скрипт. Соответственно, нужны ли мне INTEL_IOMMU_DEFAULT_ON и intel_iommu=on в этом случае? На этом же железе и трафике netmap справляется с нагрузкой адекватно.

TCP/IP для сокетов сами писать собираетесь?
1. Да, INTEL_IOMMU_DEFAULT_ON и intel_iommu=on нужны. Если netmap справляется, значит нет требований к доступности и можно не заморачиваться — брать и использовать. DPDK нужен там где нужна максимальная доступность (минимальная задержка перед возможностью обработки следующего запроса).
2. Ага, пишу.
Привет, нашел эту статью через поиск. Просто хочу сказать спасибо :)

Интересно. Особо интересно склеить это с джавой...

Существуют ещё Netmap, OpenOnload и pf_ring.

А PacketShader?
PacketShader не рассматриваю так как он стены корейского Kaist'a с 2010'го не покинул.
Из-за низкой энергоэффективности и сомнительного вертикального масштабирования использование GPGPU для подобных задач довольно нецелесообразно. Естественно можно использовать всякие Xeon Phi или Tile GX, и они будут гораздо эффективнее. Иногда дешевле просто взять два старичка E5-2697 v2, просто потому что их уже давно купили и списали. На практике получается что решения на основе того же Kintex 7 и Kintex Ultrascale дешевле и эффективнее, сужу по тому же Mellanox Innova Flex 4, к примеру.
Я сейчас пишу Scala фреймворк на Scala-Native c интеграцией DPDK.
До выхода Java9 нет смысла колупаться — слишком много надо патчить в OpenJDK.
В общем Netty + DPDK потеряла актуальность из-за кучи оверхедов о которых я тогда и предположить не мог.
Сейчас вышло SPDK — есть задумки прикрутить хранилище на SPDK к PostgreSQL и ScyllaDB.

Статью оставил сугубо по историческим причинам.

Часть 1 может быть весной 2017ого, может…
Еще про DPDK попытаю с нубскими вопросам ))

Как я понял, к nic ходит только один демон — но можно цепляться вторым демоном к первому через ipc (shmem итд)
А вот есть ли общий «мастер» демон из коробки — или ovs может таким быть?

Понятие "Демона" отсутствует — используется свой планировщик с поддержкой афинности (affinity), всё в foreground'e без переключения контекста выполнения процесса. Получается так что логические ядра жёстко привязаны к процессу с DPDK. Пакеты складываются непосредственно в оперативку и большие страницы (huge pages) без участия процессора через RDMA, а целевой процесс с DPDK ловит единичное прерывание по заполнению буфера или других критериев. Доступ к сетевому интерфейсу монопольный посредством VFIO и IOMMU. Любое IPC через shmem подразумевает копирование с целевого буфера, что сильно повлияет на производительность. Идея DPDK в том что бы успевать обработать инфу в существующем буфере пока сетевуха пишет в соседний, любое копирование значительно снизит производительность. Грубо-говоря надо успевать обработать 1 клиентский запрос за 500-600 тактов процессора, желательно с использованием SIMD операций и Cache Streaming подходом. shmem используется только в качестве коммуникации для QEMU с ivshmem.


Кроме OVS есть ещё outscale/butterfly, возможно его использование в вашем случае будет более целесообразным. Так же есть порт BSD TCP/IP стэка на DPDK.


Надеюсь стало чуток понятнее.

Я скорее о http://dpdk.org/doc/guides/prog_guide/multi_proc_support.html — и о возможности ovs быть тем самым primary process — чтоб несколько secondary process были уже моими

Не уверен что это целесообразно — там есть много подводных камней на подобие влияния ASLR.

А как тогда свичь сделать который будет работать поверх ovs?
К примеру L7 load balancer или еще какой апп специфичный роутер?
Оно конечно нужно чтобы приложение и с внешним свичем работало — но хотелосьбы чтоб и с ovs могло нормально.
Тут оказывается есть BESS — и у него адовейший перф против ovs — https://dpdksummit.com/Archive/pdf/2016USA/Day02-Session06-ChristianMaciocco-DPDKUSASummit2016.pdf.

Так вот — судя по всему DPDK vHost порт и в OVS и в BESS можно поднять, и через DPDK работать (правда там везде VM указана — но думается это не криминально раз оно через очереди DPDK работает). Это даже более разумно чем в пайплайн встраиваться.

Не знаю, не колупал BESS.

BTW OFP не смотрел?

Смотрел, пробовал, пока с ним есть проблемы.

Можешь кратко описать по какой части? Или лучше в мыло?
Тоже случайно нашел статью, большое спасибо.

Мог бы написать поболее, но NDA не позволяет.
Перепробовал все llvm'ые языки — имеет место быть проблема: "как обработать пользовательский запрос за 600 тактов процессора", по этому сполз на строковые инструкции с SSE2 SSE4.2 AVX2 AVX512, в зависимости от размера строк выполняю динамическую кодогенерацию… и надо использовать Cache Streaming подходы.


Пока нет нормальных программных реализаций которые могли бы нагрузить нормально сетевые интерфейсы до максимальной пропускной способности — нужно over 48 ядер на 10ти гигабитный интерфейс.

Тут коллеги писали что
Фактически 12 ядер процессора Intel Xeon E5-2680v3 могут обрабатывать 10 гигабит трафика syn/ack/data флуда.

habrahabr.ru/post/301892 Может будет польза.

За статью спасибо.

Я имел ввиду полноценный http rest :p


Ну как бэ уже успел написать свой функциональный язык (каппа-числение со стрелками и лямбдами, каппа — это лямбда без HoF'a, но с делегатами), с компилятором и native/llvm/jvm/js/wasm таргетами, в свободное время пишу стандартную либу.


Там отдельным таргетом будет DPDK \o/
Также планирую портировать как-нить сам DPDK и poll-mode драйвера, правда нету денег на железки и тесты.


Мои страдания с попытками интегрировать DPDK куда-попало увенчались ничем.
Надеялся что в Java9 допилят Project Panama и старые глюки уйдут — ниповезло.
По этому дальше публиковать статьи особо нету смысла...

допилят Project Panama и старые глюки уйдут
Что за глюки?

Грубо говоря там есть очень большие проблемы в стоимости interop'a в FFI, и очень сильно не хватает как оптимизаций JIT'a так и просто оптимизаций объектной модели — слишком много overhead'a от legacy хлама.

И даже Unsafe не помогает с off-heap размещением данных? Кстати, видели вот это github.com/sooty1892/packet-pro?

Даже в Unsafe с Offheap'ом overhead будет пропускную способность сильно прогинать.


JVM в афинном окружении очень странно работает: если просто писать с аффинных потоков в буфер и обрабатывать банальным Poll'ом — там бывают всякие странные артефакты (livelock'и например) из-за отсутствия нормальной синхронизации.


Unsafe+Offheap может выжать где-то 400-500К RPS, и то на захват с 10Gbit'ного интерфейса, вангую что реально там будет где-то 5-6Gbit со всеми мучениями, потом будут "глюки и радости".


Нет, конкретно это не видел: подход понятен, но морально устарело.

Жаль, что продолжения нет, я сейчас ковыряю и это боль в одном месте. Аудитория, конечно, небольшая, но своего читателя подобные статьи найдут.

Понятное дело, Спасибо за доброе слово.
Могу смело утверждать что ситуацию очень сильно усугубляет нестабильность существующих прошивок и неразвитые механизмы их обновления.


Планирую как нить сесть и переписать сам DPDK с нуля, но это будет не скоро.
Может быть напишу статейку про свой язык на хабр, правда аудитория тут довольно колоритная.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.