Comments 14
>копируется в основную память с помощью механизма DMA — Direct Memory Access
На достаточно свежем железе, копируется в last level cache того сокета, откуда инициировали DMA. И уже оттуда в память.
Вообще, хороший tutorial, но у читателя может сложиться впечатление (так как имеется сравнение с сетевым стеком линукс), что в dpdk есть сетевой стек, и он, например, умеет работать с tcp — собирать tcp, устанавливать соединение и тд.
На достаточно свежем железе, копируется в last level cache того сокета, откуда инициировали DMA. И уже оттуда в память.
Вообще, хороший tutorial, но у читателя может сложиться впечатление (так как имеется сравнение с сетевым стеком линукс), что в dpdk есть сетевой стек, и он, например, умеет работать с tcp — собирать tcp, устанавливать соединение и тд.
может сложиться впечатление ..., что в dpdk есть сетевой стек
Есть смелые ребята, которые свой TCP написали поверх DPDK: http://www.seastar-project.org/
Пока лично руками не щупал, но в перспективе собираюсь...
Подкрутить к DPDK user mode TCP стэк — обычный пример, но мощИ обычно хватает, если сначала в dpdk app смотреть на пакетик, и отдавать TCP стэку только избранные, редкие flow.
На систар не смотрел, он на плюсах, по мне так низкоуровневые сетевые вещи должны быть на чистом С (это не предмет для спора, считайте это предубеждениями).
На прошлой неделе в Дублине на dpdksummit в кулуарах общался на тему юзерспейс тсп стеков, узнал много ньюансов из первых рук. Попробую собрать тут по крупицам инфу. На данный момент дела обстоят так:
https://github.com/rumpkernel/drv-netif-dpdk — стек netbsd, как есть, не быстрый, проект не развивается
https://github.com/eunyoung14/mtcp — проект автора packetshader (KyoungSoo Park), так же не блещет скоростью. По словам KyoungSoo их главная цель не скорость, а стройный код и модульность.
https://github.com/scylladb/seastar — C++, больше о нем ничего не знаю
https://github.com/OpenFastPath/ofp — со слов коллег, вроде бы достаточно быстр (локи вычищены), опирается на ODP — абстракцию над DPDK (и не только), имеются проблемы со стабильностью.
https://github.com/opendp/dpdk-ans — закрытые исходники
https://wiki.fd.io/view/Project_Proposals/TLDK — проект, развиваемый в рамках VPP, интел ставит пока на него, правда нет публичной реализации ТСП (есть на данный момент внутри интела)
http://www.6wind.com/solutions/tcp/ — закрытый, коммерческий, но вроде как быстрый
На прошлой неделе в Дублине на dpdksummit в кулуарах общался на тему юзерспейс тсп стеков, узнал много ньюансов из первых рук. Попробую собрать тут по крупицам инфу. На данный момент дела обстоят так:
https://github.com/rumpkernel/drv-netif-dpdk — стек netbsd, как есть, не быстрый, проект не развивается
https://github.com/eunyoung14/mtcp — проект автора packetshader (KyoungSoo Park), так же не блещет скоростью. По словам KyoungSoo их главная цель не скорость, а стройный код и модульность.
https://github.com/scylladb/seastar — C++, больше о нем ничего не знаю
https://github.com/OpenFastPath/ofp — со слов коллег, вроде бы достаточно быстр (локи вычищены), опирается на ODP — абстракцию над DPDK (и не только), имеются проблемы со стабильностью.
https://github.com/opendp/dpdk-ans — закрытые исходники
https://wiki.fd.io/view/Project_Proposals/TLDK — проект, развиваемый в рамках VPP, интел ставит пока на него, правда нет публичной реализации ТСП (есть на данный момент внутри интела)
http://www.6wind.com/solutions/tcp/ — закрытый, коммерческий, но вроде как быстрый
Спасибо за уточнение по поводу DMA!
День добрый! Пожалуй поворчу немного, вы уж сильно не обижайтесь =)
Уже без Intel, просто DPDK
Необходимо понимать, что
по этому слинковать приложение, используюещее сокет апи с дпдк просто так в лоб не получится (на самом деле на сегодняшний день существует ряд TCP стеков поверх дпдк — rumptcp, mtcp(кстати от автора packetshader))
На самом деле кольцевая структура — rx ring — это кольцо дескрипторов. В этой структуре не содержатся сами пакеты (они сперва попадают в fifo буфер NIC), там содержатся указатели на область памяти, куда делать DMA + ряд других полей, куда NIC пишет после успешного DMA (write back), например длина пакета, оффлоадинг флаги итд.
Современные сетевые умеют в interrupt moderation
Что касается sk_buff, да структура очень разрослась, к тому же поля расположены не лучшим образом.
На самом деле на данный момент в библиотеке целый скоп различных PMD для большинства современных сетевых карт + PMD виртуальных устройств + misc (af_packet, pcap, null etc...)
Это нужно для того, чтобы не вымывать дичайше TLB
Што?
Нет. Во-первых, то, что вы называете головой и хвостом в rte_ring.h называется prod.head и cons.head
Во-вторых, в случае enqueue CAS'ом апдейтится prod.head (увеличивается на кол-во вставляемых объектов)
__rte_ring_mp_do_enqueue()
, а в случае dequeue — cons.head.
__rte_ring_mc_do_dequeue()
Ничего не понятно что вы имели ввиду. С одной стороны — да, rte_mbuf сильно меньше sk_buff, но его нельзя сравнивать с так же разросшимся mbuf во FreeBSD. Более того, во Фре есть сами mbuf, которые могут нести короткие пакеты (если я не ошибаюсь до 128 байт) и mbuf_cluster — соответственно для больших.
Что же касается причин столь высокой производительности библиотек — их пишут довольно квалифицированные люди. На вскидку для ускорения обработки используются техники: выравнивание, батч обработка пакетов (+ векторизация), префетчинг (особенно полезен при пайплайнинге), поллинг (отказ от прерываний), использование hugepages (меньше трешим TLB), lockless fastpath (должны отсутствать блокировки в коде обработки пакетов), тред аффинити (меньше трешит кеши), итд.
Вот для примера Брюс Ричардсон несколько часов назад читал доклад, в котором показал один из кейсов поиска узкого места.
В любом случае — спасибо за популяризацию DPDK.
Intel DPDK
Уже без Intel, просто DPDK
Они позволяют полностью исключить сетевой стек Linux из процесса обработки пакетов и сделать так, чтобы приложение, работающее в пользовательском пространстве, взаимодействовало с сетевым устройством напрямую
Необходимо понимать, что
DPDK is not a networking stack
по этому слинковать приложение, используюещее сокет апи с дпдк просто так в лоб не получится (на самом деле на сегодняшний день существует ряд TCP стеков поверх дпдк — rumptcp, mtcp(кстати от автора packetshader))
когда пакет поступает на сетевую карту, он сначала попадает в специальную кольцевую структуру, — приёмную очередь (receive queue или просто RX). Оттуда он копируется в основную память с помощью механизма DMA — Direct Memory Access.
На самом деле кольцевая структура — rx ring — это кольцо дескрипторов. В этой структуре не содержатся сами пакеты (они сперва попадают в fifo буфер NIC), там содержатся указатели на область памяти, куда делать DMA + ряд других полей, куда NIC пишет после успешного DMA (write back), например длина пакета, оффлоадинг флаги итд.
прерывание генерируется всякий раз, когда новый пакет поступает в систему
Современные сетевые умеют в interrupt moderation
Что касается sk_buff, да структура очень разрослась, к тому же поля расположены не лучшим образом.
входящий в DPDK драйвер PMD
На самом деле на данный момент в библиотеке целый скоп различных PMD для большинства современных сетевых карт + PMD виртуальных устройств + misc (af_packet, pcap, null etc...)
Для работы с DPDK необходимо также настроить большие страницы памяти (hugepages). Это нужно, чтобы выделять большие регионы памяти и записывать в них данные.
Это нужно для того, чтобы не вымывать дичайше TLB
Можно сказать, что hugepages в DPDK выполняют ту же роль, что механизм DMA в традиционной обработке пакетов.
Што?
заключается в том, чтобы поменять голову и хвост местами
Нет. Во-первых, то, что вы называете головой и хвостом в rte_ring.h называется prod.head и cons.head
Во-вторых, в случае enqueue CAS'ом апдейтится prod.head (увеличивается на кол-во вставляемых объектов)
__rte_ring_mp_do_enqueue()
, а в случае dequeue — cons.head.
__rte_ring_mc_do_dequeue()
во многом напоминает тот, что используется в FreeBSD: вместо одной большой структуры sk_buff — много буферов rte_mbuf небольшого размера.
Ничего не понятно что вы имели ввиду. С одной стороны — да, rte_mbuf сильно меньше sk_buff, но его нельзя сравнивать с так же разросшимся mbuf во FreeBSD. Более того, во Фре есть сами mbuf, которые могут нести короткие пакеты (если я не ошибаюсь до 128 байт) и mbuf_cluster — соответственно для больших.
Что же касается причин столь высокой производительности библиотек — их пишут довольно квалифицированные люди. На вскидку для ускорения обработки используются техники: выравнивание, батч обработка пакетов (+ векторизация), префетчинг (особенно полезен при пайплайнинге), поллинг (отказ от прерываний), использование hugepages (меньше трешим TLB), lockless fastpath (должны отсутствать блокировки в коде обработки пакетов), тред аффинити (меньше трешит кеши), итд.
Вот для примера Брюс Ричардсон несколько часов назад читал доклад, в котором показал один из кейсов поиска узкого места.
В любом случае — спасибо за популяризацию DPDK.
К сожалению, в течение последних двух дней был вдалеке от компьютера и Интернета, поэтому отвечаю только сейчас.
Обижаться и никто и не собирается =) Более того, моя реакция будет совершенно противоположной: я очень рад, что вы внимательно прочитали статью и благодарен вам за конструктивные замечания. Вообще, обижаться на критику, если она конструктивная — это не про меня. Я не боюсь признавать свои ошибки, а тот же Хабр считаю местом не для демонстрации собственной крутизны, а для дискуссий, взаимного обучения и обмена мнениями.
Прекрасно понимаю и сейчас жалею, что ясно не выразил это в тексте.Спасибо за замечание. Про TCP-стеки поверх DPDK обязательно почитаю поподробнее (кстати, если знаете полезные ссылки по теме, буду очень признателен).
Это я знаю; в тексте выразился не совсем удачно. Все указанные вами сомнительные и неудачные фразы я либо отредактировал, либо вообще убрал.
Это я знаю. Там ещё prod.tail и cons.tail есть. И здесь мы уже из обсуждения чисто технических деталей смещаемся в плоскость терминологии и стилистики. Конечно, в тексте можно писать как в rte_ring.h — но это делает его более тяжеловесным и нечитабельным. Я не пурист, не против заимствования терминов из других языков (если в нашем языке таковых нет), но ералаша из русских и латинских букв в тексте не люблю. К тому же термины «голова» и «хвост» применительно к кольцевому буферу в русском языке можно считать общеупотребительными.
Насколько я понимаю, истоки идеи, лежащей в основе rte_mbuf, восходят к FreeBSD. Если в Linux для всех типов пакетов используется структура sk_buff (о недостатках такого подхода мы уже говорили выше), то в FreeBSD используются mbuf, которая гораздо меньше по размеру и которые для обработки больших пакетов могут объединяться друг с другом (как buffer chaining в DPDK). Когда я прочитал про rte_mbuf, мне это сразу напомнило «фряху».
За ссылку на доклад огромное спасибо!
В заключение хочу ещё раз поблагодарить вас за все высказанные замечания, эта как раз так критика, которая помогает нам стать лучше =). Именно ваш комментарий оказался самым ценным из всех.
При работе над следующей статьёй многие ваши замечания я буду держать в уме.
И хотел бы спросить: а где вы так хорошо изучили DPDK? используете ли вы DPDK для решения каких-то практических задач? Заранее благодарю и надеюсь на продолжение диалога.
… вы уж сильно не обижайтесь =)
Обижаться и никто и не собирается =) Более того, моя реакция будет совершенно противоположной: я очень рад, что вы внимательно прочитали статью и благодарен вам за конструктивные замечания. Вообще, обижаться на критику, если она конструктивная — это не про меня. Я не боюсь признавать свои ошибки, а тот же Хабр считаю местом не для демонстрации собственной крутизны, а для дискуссий, взаимного обучения и обмена мнениями.
по этому слинковать приложение, используюещее сокет апи с дпдк просто так в лоб не получится (на самом деле на сегодняшний день существует ряд TCP стеков поверх дпдк — rumptcp, mtcp(кстати от автора packetshader))
Прекрасно понимаю и сейчас жалею, что ясно не выразил это в тексте.Спасибо за замечание. Про TCP-стеки поверх DPDK обязательно почитаю поподробнее (кстати, если знаете полезные ссылки по теме, буду очень признателен).
На самом деле кольцевая структура — rx ring — это кольцо дескрипторов. В этой структуре не содержатся сами пакеты (они сперва попадают в fifo буфер NIC), там содержатся указатели на область памяти, куда делать DMA + ряд других полей, куда NIC пишет после успешного DMA (write back), например длина пакета, оффлоадинг флаги итд.
Это я знаю; в тексте выразился не совсем удачно. Все указанные вами сомнительные и неудачные фразы я либо отредактировал, либо вообще убрал.
… то, что вы называете головой и хвостом в rte_ring.h называется prod.head и cons.head
Это я знаю. Там ещё prod.tail и cons.tail есть. И здесь мы уже из обсуждения чисто технических деталей смещаемся в плоскость терминологии и стилистики. Конечно, в тексте можно писать как в rte_ring.h — но это делает его более тяжеловесным и нечитабельным. Я не пурист, не против заимствования терминов из других языков (если в нашем языке таковых нет), но ералаша из русских и латинских букв в тексте не люблю. К тому же термины «голова» и «хвост» применительно к кольцевому буферу в русском языке можно считать общеупотребительными.
Ничего не понятно что вы имели ввиду. С одной стороны — да, rte_mbuf сильно меньше sk_buff, но его нельзя сравнивать с так же разросшимся mbuf во FreeBSD.
Насколько я понимаю, истоки идеи, лежащей в основе rte_mbuf, восходят к FreeBSD. Если в Linux для всех типов пакетов используется структура sk_buff (о недостатках такого подхода мы уже говорили выше), то в FreeBSD используются mbuf, которая гораздо меньше по размеру и которые для обработки больших пакетов могут объединяться друг с другом (как buffer chaining в DPDK). Когда я прочитал про rte_mbuf, мне это сразу напомнило «фряху».
Вот для примера Брюс Ричардсон несколько часов назад читал доклад, в котором показал один из кейсов поиска узкого места.
За ссылку на доклад огромное спасибо!
В заключение хочу ещё раз поблагодарить вас за все высказанные замечания, эта как раз так критика, которая помогает нам стать лучше =). Именно ваш комментарий оказался самым ценным из всех.
При работе над следующей статьёй многие ваши замечания я буду держать в уме.
И хотел бы спросить: а где вы так хорошо изучили DPDK? используете ли вы DPDK для решения каких-то практических задач? Заранее благодарю и надеюсь на продолжение диалога.
UFO just landed and posted this here
Вообще от поллинга отказались, ибо проц в холостую пашет, но зато задержки типа меньше.
Если честно, не понял, что вы имеете в виду. Попробуйте, пожалуйста, сформулировать эту мысль другими словами.
DPDK вроде как прибит на гвозди к интелу.
Да, DPDK был создан Intel для собственных сетевых карт. Драйверы для других карт (<a href=«http://dpdk.org/doc/guides/nics/mlx4.html» target="_blank" rel=«nofollow»">Mellanox, Emulex) есть, но с ними далеко не все гладко. Например, во время экспериментов с DPDK мы установили драйвер для Mellanox, но ничего не завелось, хотя всё делали точь-в-точь по инструкции. Зато все получилось сразу, как только мы заменили карту Mellanox на Intel.
netmap работает с кучей железа, там есть какие то минимальные требования к самим сетевухам, типа наличия DMA и колец дескрипторов.
Автор — Луиджи впилил поддержку в дрова реалтека, интела и пр.
Да, netmap гораздо менее «завендорлочен». Ну и тут есть свои подводные камни: например, полноценной поддержки карт Mellanox нет до сих пор (см. здесь).
Вообще от поллинга отказались
А кто отказался то? Если говорить про dpdk — там в основном все приложения крутятся в busy loop.
DPDK вроде как прибит на гвозди к интелу.
Нет, это абсолютно не так.
netmap работает с кучей железа
man netmap
…
netmap supports the following interfaces: em(4), ixgbe(4), re(4)
…
А про dpdk можно почитать прям на главной
It was designed to run on any processors. The first supported CPU was Intel x86 and it is now extended to IBM Power 8, EZchip TILE-Gx and ARM.
Список поддерживаемых сетевых карт
Sign up to leave a comment.
Введение в DPDK: архитектура и принцип работы