Comments 31
Возможно непопулярность связана с тем, что никто и не видел, что эта статья появилась?
Может за одно подскажите, двухпортовый 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. обновите прошивку карты.
TCP/IP для сокетов сами писать собираетесь?
2. Ага, пишу.
Интересно. Особо интересно склеить это с джавой...
Существуют ещё Netmap, OpenOnload и pf_ring.
А PacketShader?
Из-за низкой энергоэффективности и сомнительного вертикального масштабирования использование GPGPU для подобных задач довольно нецелесообразно. Естественно можно использовать всякие Xeon Phi или Tile GX, и они будут гораздо эффективнее. Иногда дешевле просто взять два старичка E5-2697 v2, просто потому что их уже давно купили и списали. На практике получается что решения на основе того же Kintex 7 и Kintex Ultrascale дешевле и эффективнее, сужу по тому же Mellanox Innova Flex 4, к примеру.
До выхода Java9 нет смысла колупаться — слишком много надо патчить в OpenJDK.
В общем Netty + DPDK потеряла актуальность из-за кучи оверхедов о которых я тогда и предположить не мог.
Сейчас вышло SPDK — есть задумки прикрутить хранилище на SPDK к PostgreSQL и ScyllaDB.
Статью оставил сугубо по историческим причинам.
Часть 1 может быть весной 2017ого, может…
Как я понял, к 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.
Надеюсь стало чуток понятнее.
Не уверен что это целесообразно — там есть много подводных камней на подобие влияния ASLR.
К примеру L7 load balancer или еще какой апп специфичный роутер?
Оно конечно нужно чтобы приложение и с внешним свичем работало — но хотелосьбы чтоб и с ovs могло нормально.
Так вот — судя по всему DPDK vHost порт и в OVS и в BESS можно поднять, и через DPDK работать (правда там везде VM указана — но думается это не криминально раз оно через очереди DPDK работает). Это даже более разумно чем в пайплайн встраиваться.
Мог бы написать поболее, но 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 с Offheap'ом overhead будет пропускную способность сильно прогинать.
JVM в афинном окружении очень странно работает: если просто писать с аффинных потоков в буфер и обрабатывать банальным Poll'ом — там бывают всякие странные артефакты (livelock'и например) из-за отсутствия нормальной синхронизации.
Unsafe+Offheap может выжать где-то 400-500К RPS, и то на захват с 10Gbit'ного интерфейса, вангую что реально там будет где-то 5-6Gbit со всеми мучениями, потом будут "глюки и радости".
Нет, конкретно это не видел: подход понятен, но морально устарело.
Понятное дело, Спасибо за доброе слово.
Могу смело утверждать что ситуацию очень сильно усугубляет нестабильность существующих прошивок и неразвитые механизмы их обновления.
Планирую как нить сесть и переписать сам DPDK с нуля, но это будет не скоро.
Может быть напишу статейку про свой язык на хабр, правда аудитория тут довольно колоритная.
Использование DPDK для обеспечения высокой производительности прикладных решений (часть 0)